Re: [C PATCH]: allow aliasing of compatible types derived from enumeral types [PR115157]

On Thu, 23 May 2024, Ian Lance Taylor wrote: > On Thu, May 23, 2024 at 2:48 PM Martin Uecker wrote: > > > > Am Donnerstag, dem 23.05.2024 um 14:30 -0700 schrieb Ian Lance Taylor: > > > On Thu, May 23, 2024 at 2:00 PM Joseph Myers wrote: > > > > > > > > On Tue, 21 May 2024, Martin Uecker wrote:

Re: [PATCH] RISC-V: Avoid splitting store dataref groups during SLP discovery

On Thu, 23 May 2024, Richard Biener wrote: > The following avoids splitting store dataref groups during SLP > discovery but instead forces (eventually single-lane) consecutive > lane SLP discovery for all lanes of the group, creating VEC_PERM > SLP nodes merging them so the store will always

[PATCH V2] RISC-V: Fix missing boolean_expression in zmmul extension

Update v1->v2 Add testcase for this patch. Missing boolean_expression TARGET_ZMMUL in riscv_rtx_costs() cause different instructions when multiplying an integer with a constant. ( https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1482 ) int foo(int *ib) { *ib = *ib * 33938;

[to-be-committed][v2][RISC-V] Use bclri in constant synthesis

Testing with Zbs enabled by default showed a minor logic error. After the loop clearing things with bclri, we can only use the sequence if we were able to clear all the necessary bits. If any bits are still on, then the bclr sequence turned out to not be profitable. -- So this is

Re: [PATCH 1/2] Simplify (AND (ASHIFTRT A imm) mask) to (LSHIFTRT A imm) for vector mode.

CC for review. On Tue, May 21, 2024 at 1:12 PM liuhongt wrote: > > When mask is (1 << (prec - imm) - 1) which is used to clear upper bits > of A, then it can be simplified to LSHIFTRT. > > i.e Simplify > (and:v8hi > (ashifrt:v8hi A 8) > (const_vector 0xff x8)) > to > (lshifrt:v8hi A 8) > >

Re: [PATCH 1/2] c++/modules: Fix treatment of unnamed types

On Thu, May 23, 2024 at 03:36:48PM -0400, Jason Merrill wrote: > On 5/23/24 09:27, Nathaniel Shead wrote: > > On Mon, May 20, 2024 at 06:00:09PM -0400, Jason Merrill wrote: > > > On 5/17/24 02:14, Nathaniel Shead wrote: > > > > On Tue, May 14, 2024 at 06:21:48PM -0400, Jason Merrill wrote: > > > >

Re: [PATCH] missing reuire target has_arch_ppc64 for pr106550.c

Hi, >>> --- >>> gcc/testsuite/gcc.target/powerpc/pr106550.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106550.c >>> b/gcc/testsuite/gcc.target/powerpc/pr106550.c >>> index 74e395331ab..146514b3adf 100644 >>> ---

Re: [PATCH V3] report message for operator %a on unaddressible operand

Hi, Hans-Peter Nilsson writes: > On Mon, 20 May 2024, Jiufu Guo wrote: > >> Hi, >> >> For PR96866, when printing asm code for modifier "%a", an addressable >> operand is required. While the constraint "X" allow any kind of >> operand even which is hard to get the address directly. e.g.

[PATCH v2] c++: mark TARGET_EXPRs for function arguments eliding [PR114707]

On Thu, May 23, 2024 at 04:04:13PM -0400, Jason Merrill wrote: > On 5/23/24 10:41, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > Coming back to our discussion in > > : >

Re: [PATCH V3] report message for operator %a on unaddressible operand

On Mon, 20 May 2024, Jiufu Guo wrote: > Hi, > > For PR96866, when printing asm code for modifier "%a", an addressable > operand is required. While the constraint "X" allow any kind of > operand even which is hard to get the address directly. e.g. extern > symbol whose address is in TOC. > An

[PATCH v2] c++/modules: Improve errors for bad module-directives [PR115200]

On Thu, May 23, 2024 at 05:11:39PM -0400, Jason Merrill wrote: > On 5/23/24 10:54, Nathaniel Shead wrote: > > Bootstrapped and regtested (so far just modules.exp and dg.exp) on > > x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds? > > > > -- >8 -- > > > > This fixes an ICE when a

[PATCH] c++: extend -Wself-move for mem-init-list [PR109396]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- We already warn for: x = std::move (x); which triggers: warning: moving 'x' of type 'int' to itself [-Wself-move] but bug 109396 reports that this doesn't work for a member-initializer-list: X() : x(std::move (x))

Re: [PATCH] rs6000: Adjust -fpatchable-function-entry* support for dual entry [PR112980]

On Wed, May 8, 2024 at 1:33 AM Kewen.Lin wrote: > > Hi Richi, > > >> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > >> index c584664e168..58e48f7dc55 100644 > >> --- a/gcc/doc/invoke.texi > >> +++ b/gcc/doc/invoke.texi > >> @@ -18363,11 +18363,11 @@ If @code{N=0}, no pad location is

PING Re: PING Re: [PATCH RFA (cgraph)] c++: pragma target and static init [PR109753]

Ping On 5/14/24 17:21, Jason Merrill wrote: Ping On 5/2/24 09:54, Jason Merrill wrote: Tested x86_64-pc-linux-gnu, OK for trunk?  14.2? This two-year-old thread seems relevant: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593410.html -- 8< --   #pragma target and optimize should

Re: [PATCH v2] libstdc++: Fix std::ranges::iota not included in numeric [PR108760]

On Fri, 17 May 2024, Michael Levine (BLOOMBERG/ 731 LEX) wrote: > This is the revised version of my patch incorporating the provided feedback > from Patrick Palka and Jonathan Wakely. > This patch fixes GCC Bug 108760: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760 > I moved

Re: [PATCH][14 backport] c++: Fix instantiation of imported temploid friends [PR114275]

On 5/13/24 07:56, Nathaniel Shead wrote: @@ -11751,9 +11767,16 @@ tsubst_friend_class (tree friend_tmpl, tree args) if (tmpl != error_mark_node) { /* The new TMPL is not an instantiation of anything, so we -forget its origins. We don't reset

Re: [PATCH] c++: alias CTAD and copy deduction guide [PR115198]

On 5/23/24 17:42, Patrick Palka wrote: On Thu, 23 May 2024, Jason Merrill wrote: On 5/23/24 14:06, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- Here we're neglecting to update DECL_NAME during the alias CTAD guide

Re: [PATCH][14 backport] c++: Fix instantiation of imported temploid friends [PR114275]

On Mon, 13 May 2024, Nathaniel Shead wrote: > > > @@ -11751,9 +11767,16 @@ tsubst_friend_class (tree friend_tmpl, tree args) > > > if (tmpl != error_mark_node) > > > { > > > /* The new TMPL is not an instantiation of anything, so we > > > - forget its origins.

Re: [PATCH] [RFC] Target-independent store forwarding avoidance. [PR48696] Target-independent store forwarding avoidance.

On Thu, 23 May 2024 at 18:18, Andrew Pinski wrote: > > On Thu, May 23, 2024 at 8:01 AM Manolis Tsamis > wrote: > > > > This pass detects cases of expensive store forwarding and tries to avoid > > them > > by reordering the stores and using suitable bit insertion sequences. > > For example it

Re: [PATCH v26 01/13] libstdc++: Optimize std::is_const compilation performance

On Thu, May 23, 2024 at 3:15 PM Patrick Palka wrote: > > On Sat, 11 May 2024, Ken Matsui wrote: > > > This patch optimizes the compilation performance of std::is_const > > by dispatching to the new __is_const built-in trait. > > This patch series LGTM Thank you! > > > > >

Re: [PATCH v26 01/13] libstdc++: Optimize std::is_const compilation performance

On Sat, 11 May 2024, Ken Matsui wrote: > This patch optimizes the compilation performance of std::is_const > by dispatching to the new __is_const built-in trait. This patch series LGTM > > libstdc++-v3/ChangeLog: > > * include/std/type_traits (is_const): Use __is_const built-in >

Re: [PATCH] libstdc++: Implement ranges::concat_view from P2542R7

On Mon, 29 Apr 2024, Jonathan Wakely wrote: > On Mon, 22 Apr 2024 at 22:43, Patrick Palka wrote: > > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? More tests > > are needed but I figured I'd submit this now for possible consideration into > > GCC 14 since we're getting close to

Re: [C PATCH]: allow aliasing of compatible types derived from enumeral types [PR115157]

On Thu, May 23, 2024 at 2:48 PM Martin Uecker wrote: > > Am Donnerstag, dem 23.05.2024 um 14:30 -0700 schrieb Ian Lance Taylor: > > On Thu, May 23, 2024 at 2:00 PM Joseph Myers wrote: > > > > > > On Tue, 21 May 2024, Martin Uecker wrote: > > > > > > > > C: allow aliasing of compatible types

Re: [C PATCH]: allow aliasing of compatible types derived from enumeral types [PR115157]

Am Donnerstag, dem 23.05.2024 um 14:30 -0700 schrieb Ian Lance Taylor: > On Thu, May 23, 2024 at 2:00 PM Joseph Myers wrote: > > > > On Tue, 21 May 2024, Martin Uecker wrote: > > > > > > C: allow aliasing of compatible types derived from enumeral types > > > [PR115157] > > > > > >

Re: [PATCH] c++: alias CTAD and copy deduction guide [PR115198]

On Thu, 23 May 2024, Jason Merrill wrote: > On 5/23/24 14:06, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > > OK for trunk/14? > > > > -- >8 -- > > > > Here we're neglecting to update DECL_NAME during the alias CTAD guide > > transformation, which

Re: [C PATCH]: allow aliasing of compatible types derived from enumeral types [PR115157]

On Thu, May 23, 2024 at 2:00 PM Joseph Myers wrote: > > On Tue, 21 May 2024, Martin Uecker wrote: > > > > C: allow aliasing of compatible types derived from enumeral types > > [PR115157] > > > > Aliasing of enumeral types with the underlying integer is now allowed > > by setting the

Re: [PATCH] c++: alias CTAD and copy deduction guide [PR115198]

On 5/23/24 14:06, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- Here we're neglecting to update DECL_NAME during the alias CTAD guide transformation, which causes copy_guide_p to return false for the transformed copy deduction

Re: [PATCH] c++/modules: Improve errors for bad module-directives [PR115200]

On 5/23/24 10:54, Nathaniel Shead wrote: Bootstrapped and regtested (so far just modules.exp and dg.exp) on x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds? -- >8 -- This fixes an ICE when a module directive is not given at global scope. Although not explicitly mentioned, it seems

Re: [C PATCH]: allow aliasing of compatible types derived from enumeral types [PR115157]

On Tue, 21 May 2024, Martin Uecker wrote: > > C: allow aliasing of compatible types derived from enumeral types > [PR115157] > > Aliasing of enumeral types with the underlying integer is now allowed > by setting the aliasing set to zero. But this does not allow aliasing >

[COMMITTED 11/12] - Make gori_map a shared component.

This patch moves the gori_map object out of the gori object, and into the range query.   it is required by gori, and will be created simultaneously with gori. The dependency data it manages has uses outside of GORI, and this makes it easier to access by the fold_using_range routines, and

[COMMITTED 06/12] tree-optimization/113879 - Add inferred ranges for range-ops based statements.

gimple_range_fold contains some shorthand fold_range routines for easy user consumption of the range-ops interface, but there is no equivalent routines for op1_range and op2_range.  This patch provides basic versions. I have started range-op documentation, but its very early days so not that

[COMMITTED 09/12] - Gori_compute inherits from gimple_outgoing_range.

This patch makes gimple_outgoing_range a base class for the GORI API, and provides basic routines for the SSA-NAME versions returning false.   gori_compute now inherits from gimple_outgoing_range and no longer needs it as a private member. This makes far more sense as GORI is adding the

[COMMITTED 05/12] - Move infer_manager to a range_query oracle.

Turn the infer_manager class into an always available oracle accessible via a range_query object.   This will make it easier to share and query inferred range info between objects and also makes the information easily accessible to any pass that is interested. This again removes the need to

[COMMITTED 12/12] - Move condexpr_adjust into gimple-range-fold

Certain components of GORI were needed in order to process a COND_EXPR expression and calculate the 2 operands as if they were true and false edges based on the condition.   With GORI available from the range_query object now, this can be moved into the fold_using_range code where it really

[COMMITTED 10/12] - Make GORI a range_query component.

This patch moves the GORI component into the range_query object, and makes it generally available.  This makes it much easier to share between ranger, other range_queries, and the passes using them. Bootstrapped on x86_64-pc-linux-gnu with no regressions.  Pushed. From

[COMMITTED 03/12] - Rename relation oracle and API.

Could have been combined with the previous patch, but eh This changes the relation oracle accessed via a range_query to the name 'relation', as there are more oracles coming, and this is more description.  it also renames the registering and querying routines to have less redundant rext.

[COMMITTED 04/12] - Allow components to be shared among range-queries.

Ranger and ranger's cache are both range_query based, but they need to share some common components. The path ranger also needs to share the GORI component.   Up until now, they have simple copied pointers to share, but this patch provides a protected API to allow them to share without knowing

[COMMITTED 07/12] - Default gimple_outgoing_range to not process switches.

This patch adjusts the way gimple_outgoing_range works.  This is the static edge calculator that provide ranges on edges for TRUE/FALSE edges, as well as calculated the ranges on switch edges.   It was a component of ranger before or something that could be included if a pass wanted it. this

[PATCH] Use simple_dce_from_worklist in phiprop

I noticed that phiprop leaves around phi nodes which defines a ssa name which is unused. This just adds a bitmap to mark those ssa names and then calls simple_dce_from_worklist at the very end to remove those phi nodes and all of the dependencies if there was any. This might allow us to optimize

[COMMITTED 08/12] - Gori_compute no longer inherits from gori_map.

This patch moves the gori_compute object away from inheriting a gori_map object and instead it as a local member.  Export it via map (). The gori_map object contains all the SSA name dependencies and import/export name lists for blocks.  GORI was inheriting from this originally as a

[COMMITTED 00/12] Cleanup some ranger components and make them available via range_query.

This set of 12 patches overhauls some structural component layouts in ranger and makes them available via a simple range_query API. There are 3 main groups of patches.  The first group overhauls the relation oracle a bit and makes it accessing it via range_query more transparent.  The

[COMMITTED 02/12] - Move to an always available relation oracle.

This patch provides a basic oracle which doesn't do anything, but will still respond when queried.  This allows passes to avoid the NULL check for an oracle pointer before they do anything, and results in a slight speedup in VRP, and a slightly more significant 0.3% speedup in jump threading..

[COMMITTED 01/12] - Move all relation queries into relation_oracle.

A range-query currently provides a couple of relation query routines, plus it also provides direct access to an oracle.   This patch moves those queries into the oracle where they should be, and ands the ability to create and destroy the basic dominance oracle ranger uses.  This is the usual

Re: [C PATCH, v2] Fix for redeclared enumerator initialized with different type [PR115109]

On Tue, 21 May 2024, Martin Uecker wrote: > > The constraint violated is the general one "If an identifier has no > > linkage, there shall be no more than one declaration of the identifier (in > > a declarator or type specifier) with the same scope and in the same name > > space, except that:

Re: [PATCH] Fortran: improve attribute conflict checking [PR93635]

Le 23/05/2024 à 09:49, Mikael Morin a écrit : Le 13/05/2024 à 09:25, Mikael Morin a écrit : Le 10/05/2024 à 21:56, Harald Anlauf a écrit : Am 10.05.24 um 21:48 schrieb Harald Anlauf: Hi Mikael, Am 10.05.24 um 11:45 schrieb Mikael Morin: Le 09/05/2024 à 22:30, Harald Anlauf a écrit : I'll

[pushed] c++: deleting array temporary [PR115187]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Decaying the array temporary to a pointer and then deleting that crashes in verify_gimple_stmt, because the TARGET_EXPR is first evaluated inside the TRY_FINALLY_EXPR, but the cleanup point is outside. Fixed by using get_target_expr

Re: [PATCH] c++: mark TARGET_EXPRs for function arguments eliding [PR114707]

On 5/23/24 10:41, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Coming back to our discussion in : TARGET_EXPRs that initialize a function argument are not marked TARGET_EXPR_ELIDING_P

Re: [PATCH] c++/modules: Ensure all partial specialisations are tracked [PR114947]

On 5/12/24 09:29, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- Constrained partial specialisations aren't all necessarily tracked on the instantiation table. The modules code uses a separate 'partial_specializations' table to track them

Re: [PATCH v1 2/6] Extract ix86 dllimport implementation to mingw

On Thu, May 23, 2024 at 7:53 PM Evgeny Karpov wrote: > > > Thursday, May 23, 2024 10:35 AM > Uros Bizjak wrote: > > > Richard Sandiford wrote: > > > > > > > This looks good to me apart from a couple of very minor comments > > > > below, but please get approval from the x86 maintainers as well.

Re: [PATCH 2/2] c++/modules: Remember that header units have CMIs

On 5/23/24 09:29, Nathaniel Shead wrote: And here's that patch. As far as I can tell there should be no visible change anymore, so there aren't any testcases. Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- This appears to be an oversight in the definition of

Re: [PATCH 1/2] c++/modules: Fix treatment of unnamed types

On 5/23/24 09:27, Nathaniel Shead wrote: On Mon, May 20, 2024 at 06:00:09PM -0400, Jason Merrill wrote: On 5/17/24 02:14, Nathaniel Shead wrote: On Tue, May 14, 2024 at 06:21:48PM -0400, Jason Merrill wrote: On 5/12/24 22:58, Nathaniel Shead wrote: Bootstrapped and regtested on

[PATCH, v2] Fortran: improve attribute conflict checking [PR93635]

Hi Mikael, On 5/23/24 09:49, Mikael Morin wrote: Le 13/05/2024 à 09:25, Mikael Morin a écrit : Le 10/05/2024 à 21:56, Harald Anlauf a écrit : Am 10.05.24 um 21:48 schrieb Harald Anlauf: Hi Mikael, Am 10.05.24 um 11:45 schrieb Mikael Morin: Le 09/05/2024 à 22:30, Harald Anlauf a écrit :

[to-be-committed] [RISC-V] Use bclri in constant synthesis

So this is conceptually similar to how we handled direct generation of bseti for constant synthesis, but this time for bclr. In the bclr case, we already have an expander for AND. So we just needed to adjust the predicate to accept another class of constant operands (those with a single bit

Re: [PATCH 12/13] rs6000, remove __builtin_vsx_xvcmpeqsp built-in

On 5/13/24 22:37, Kewen.Lin wrote: > Hi, > > on 2024/4/20 05:18, Carl Love wrote: >> rs6000, remove __builtin_vsx_xvcmpeqsp built-in >> >> The built-in __builtin_vsx_xvcmpeqsp is a duplicate of the overloaded >> vec_cmpeq built-in. The built-in is undocumented. The built-in and >> the test

[PATCH] c++: alias CTAD and copy deduction guide [PR115198]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- Here we're neglecting to update DECL_NAME during the alias CTAD guide transformation, which causes copy_guide_p to return false for the transformed copy deduction guide since DECL_NAME is still __dguide_C

Re: [PATCH v1 2/6] Extract ix86 dllimport implementation to mingw

Thursday, May 23, 2024 10:35 AM Uros Bizjak wrote: > Richard Sandiford wrote: > > > > > This looks good to me apart from a couple of very minor comments > > > below, but please get approval from the x86 maintainers as well. In > > > particular, they might prefer to handle

Re: [PATCH] Avoid vector -Wfree-nonheap-object warnings

On 23/05/2024 15:31, Jonathan Wakely wrote: On 23/05/24 06:55 +0200, François Dumont wrote: As explained in this email: https://gcc.gnu.org/pipermail/libstdc++/2024-April/058552.html I experimented -Wfree-nonheap-object because of my enhancements on algos. So here is a patch to extend the

[c-family] Another small fix to implementation of -fdump-ada-spec

This avoids generating invalid Ada code for functions with a multidimensional array parameter and also cleans things up left and right. Tested on x86-64/Linux, applied on the mainline. 2024-05-23 Eric Botcazou * c-ada-spec.cc (check_type_name_conflict): Add guard.

Re: [PATCH] [RFC] Target-independent store forwarding avoidance. [PR48696] Target-independent store forwarding avoidance.

On Thu, May 23, 2024 at 8:01 AM Manolis Tsamis wrote: > > This pass detects cases of expensive store forwarding and tries to avoid them > by reordering the stores and using suitable bit insertion sequences. > For example it can transform this: > > strbw2, [x1, 1] > ldr x0, [x1]

[PATCH] Add config file so b4 uses inbox.sourceware.org automatically

It looks like my patch[1] to make b4 figure this out automagically won't be accepted, so this makes it work for GCC. A similar commit could be done for each project hosted on sourceware.org if desired. [1] https://lore.kernel.org/tools/20240523143752.385810-1-jwak...@redhat.com/T/#u OK for

[PATCH] [RFC] Target-independent store forwarding avoidance. [PR48696] Target-independent store forwarding avoidance.

This pass detects cases of expensive store forwarding and tries to avoid them by reordering the stores and using suitable bit insertion sequences. For example it can transform this: strbw2, [x1, 1] ldr x0, [x1] # Epxensive store forwarding to larger load. To: ldr

Re: [PATCH v2] Match: Support __builtin_add_overflow branch form for unsigned SAT_ADD

On 5/23/24 6:14 AM, Richard Biener wrote: On Thu, May 23, 2024 at 1:08 PM Li, Pan2 wrote: I have a try to convert the PHI from Part-A to Part-B, aka PHI to _2 = phi_cond ? _1 : 255. And then we can do the matching on COND_EXPR in the underlying widen-mul pass. Unfortunately, meet some

[PATCH] c++/modules: Improve errors for bad module-directives [PR115200]

Bootstrapped and regtested (so far just modules.exp and dg.exp) on x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds? -- >8 -- This fixes an ICE when a module directive is not given at global scope. Although not explicitly mentioned, it seems implied from [basic.link] p1 and

RE: [PATCH v4] Match: Add overloaded types_match to avoid code dup [NFC]

Committed as passed below test suites, thanks Richard. * The rv64gcv fully regression test. * The x86 bootstrap test. * The x86 regression test. Pan -Original Message- From: Li, Pan2 Sent: Thursday, May 23, 2024 8:06 PM To: Richard Biener Cc: gcc-patches@gcc.gnu.org;

[PATCH] c++: mark TARGET_EXPRs for function arguments eliding [PR114707]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Coming back to our discussion in : TARGET_EXPRs that initialize a function argument are not marked TARGET_EXPR_ELIDING_P even though gimplify_arg drops such

[PATCH 2/2] arm: Add support for MVE Tail-Predicated Low Overhead Loops

This patch adds support for MVE Tail-Predicated Low Overhead Loops by using the doloop funcitonality added to support predicated vectorized hardware loops. gcc/ChangeLog: * config/arm/arm-protos.h (arm_target_bb_ok_for_lob): Change declaration to pass basic_block.

[PATCH 1/2] doloop: Add support for predicated vectorized loops

This patch adds support in the target agnostic doloop pass for the detection of predicated vectorized hardware loops. Arm is currently the only target that will make use of this feature. gcc/ChangeLog: * df-core.cc (df_bb_regno_only_def_find): New helper function. * df.h

[PATCH 0/2] arm, doloop: Add support for MVE Tail-Predicated Low Overhead Loops

Hi, We held these two patches back in stage 4 because they touched target-agnostic code, though I am quite confident they will not affect other targets. Given stage one has reopened, I am reposting them, I rebased them but they seem to apply cleanly on trunk. No changes from previously

Re: [RFC][PATCH] PR tree-optimization/109071 - -Warray-bounds false positive warnings due to code duplication from jump threading

> On May 23, 2024, at 10:13, David Malcolm wrote: > > On Thu, 2024-05-23 at 14:03 +, Qing Zhao wrote: > > [...snip...] > >> Is “location_adhoc_data” an available data structure in current GCC? >> I just searched GCC source tree, cannot find it. > > It's in libcpp/include/line-table.h;

Re: [RFC][PATCH] PR tree-optimization/109071 - -Warray-bounds false positive warnings due to code duplication from jump threading

On Thu, 2024-05-23 at 14:03 +, Qing Zhao wrote: [...snip...] > Is “location_adhoc_data” an available data structure in current GCC? > I just searched GCC source tree, cannot find it. It's in libcpp/include/line-table.h; see the big comment at the top of that file. Dave

Re: [RFC][PATCH] PR tree-optimization/109071 - -Warray-bounds false positive warnings due to code duplication from jump threading

> On May 23, 2024, at 07:46, Richard Biener wrote: > > On Wed, May 22, 2024 at 8:53 PM Qing Zhao wrote: >> >> >> >>> On May 22, 2024, at 03:38, Richard Biener >>> wrote: >>> >>> On Tue, May 21, 2024 at 11:36 PM David Malcolm wrote: On Tue, 2024-05-21 at 15:13 +, Qing

[PATCH] RISC-V: Avoid splitting store dataref groups during SLP discovery

The following avoids splitting store dataref groups during SLP discovery but instead forces (eventually single-lane) consecutive lane SLP discovery for all lanes of the group, creating VEC_PERM SLP nodes merging them so the store will always cover the whole group. With this for example int

Re: [PATCH] wwwdocs: contribute.html: Update consensus on patch content.

On Mon, 20 May 2024 at 15:23, Nick Clifton wrote: > > Hi Christophe, > > > I have a follow-up one: I think the same applies to binutils, but I > > don't think any maintainer / contributor expressed an opinion, and > > IIUC patch policy for binutils is (lightly) documented at > >

[PATCH] tree-optimization/115197 - fix ICE w/ constant in LC PHI and loop distribution

Forgot a check for an SSA name before trying to replace a PHI arg with its current definition. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/115197 * tree-loop-distribution.cc (copy_loop_before): Constant PHI args remain the same.

Re: [PATCH] [testsuite] conditionalize dg-additional-sources on target and type

Hi Alexandre, On Thu, 23 May 2024 at 15:29, Alexandre Oliva wrote: > > On Apr 30, 2024, Christophe Lyon wrote: > > > On Tue, 30 Apr 2024 at 01:31, Alexandre Oliva wrote: > >> >> for gcc/testsuite/ChangeLog > >> >> > >> >> * lib/target-supports.exp (check_vect_support_and_set_flags): > >> >>

Re: [PATCH] c++/modules: Ensure all partial specialisations are tracked [PR114947]

On Sun, May 12, 2024 at 11:29:39PM +1000, Nathaniel Shead wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > -- >8 -- > > Constrained partial specialisations aren't all necessarily tracked on > the instantiation table. The modules code uses a separate >

Re: [PATCH] Avoid vector -Wfree-nonheap-object warnings

On 23/05/24 06:55 +0200, François Dumont wrote: As explained in this email: https://gcc.gnu.org/pipermail/libstdc++/2024-April/058552.html I experimented -Wfree-nonheap-object because of my enhancements on algos. So here is a patch to extend the usage of the _Guard type to other parts of

[PATCH 2/2] c++/modules: Remember that header units have CMIs

And here's that patch. As far as I can tell there should be no visible change anymore, so there aren't any testcases. Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- This appears to be an oversight in the definition of module_has_cmi_p. This change will allow us to

[PATCH] [testsuite] conditionalize dg-additional-sources on target and type

On Apr 30, 2024, Christophe Lyon wrote: > On Tue, 30 Apr 2024 at 01:31, Alexandre Oliva wrote: >> >> for gcc/testsuite/ChangeLog >> >> >> >> * lib/target-supports.exp (check_vect_support_and_set_flags): >> >> Decay to link rather than compile. >> >> Alas, linking may fail because of an

[PATCH 1/2] c++/modules: Fix treatment of unnamed types

On Mon, May 20, 2024 at 06:00:09PM -0400, Jason Merrill wrote: > On 5/17/24 02:14, Nathaniel Shead wrote: > > On Tue, May 14, 2024 at 06:21:48PM -0400, Jason Merrill wrote: > > > On 5/12/24 22:58, Nathaniel Shead wrote: > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > >

Re: [PATCH] adjust vectorization expectations for ppc costmodel 76b

On Apr 29, 2024, "Kewen.Lin" wrote: > I think you can still push the patch as the testing just exposes > another issue. ACK, thanks, I've just confirmed that the problem I reported on ppc64el-linux-gnu didn't come up when testing on ppc64-vx7r2 with a non-power8 emulated cpu, so I'm going to

Re: [PATCH] RISC-V: Fix missing boolean_expression in zmmul extension

Could you add a testcase to make sure zmmul will generate mul instruction? Liao Shihua 於 2024年5月23日 週四 18:48 寫道： > Missing boolean_expression TARGET_ZMMUL in riscv_rtx_costs() casuse > different instructions when multiplying an integer with a constant. > (

Re: [PATCH v2] Match: Support __builtin_add_overflow branch form for unsigned SAT_ADD

On Thu, May 23, 2024 at 1:08 PM Li, Pan2 wrote: > > I have a try to convert the PHI from Part-A to Part-B, aka PHI to _2 = > phi_cond ? _1 : 255. > And then we can do the matching on COND_EXPR in the underlying widen-mul pass. > > Unfortunately, meet some ICE when verify_gimple_phi in sccopy1

RE: [PATCH v4] Match: Add overloaded types_match to avoid code dup [NFC]

> the above three lines are redundant. > OK with those removed. Got it, will commit it after no surprise in test for removal. Pan -Original Message- From: Richard Biener Sent: Thursday, May 23, 2024 7:49 PM To: Li, Pan2 Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai;

Re: [PATCH] .gitattributes: disable crlf translation

On Thu, May 23, 2024 at 5:50 AM Peter Damianov wrote: > > By default, git has the "autocrlf" """feature""" enabled. This causes the > files > to have CRLF line endings when checked out on windows, which in the case of > configure, causes confusing errors like: > > ./gcc/configure: line 14:

Re: [V2 PATCH] Don't reduce estimated unrolled size for innermost loop at cunrolli.

On Wed, May 22, 2024 at 7:07 AM liuhongt wrote: > > >> Hard to find a default value satisfying all testcases. > >> some require loop unroll with 7 insns increment, some don't want loop > >> unroll w/ 5 insn increment. > >> The original 2/3 reduction happened to meet all those testcases(or the >

Re: [PATCH v4] Match: Add overloaded types_match to avoid code dup [NFC]

On Thu, May 23, 2024 at 2:24 AM wrote: > > From: Pan Li > > There are sorts of match pattern for SAT related cases, there will be > some duplicated code to check the dest, op_0, op_1 are same tree types. > Aka ternary tree type matches. Thus, add overloaded types_match func > do this and

Re: [RFC][PATCH] PR tree-optimization/109071 - -Warray-bounds false positive warnings due to code duplication from jump threading

On Wed, May 22, 2024 at 8:53 PM Qing Zhao wrote: > > > > > On May 22, 2024, at 03:38, Richard Biener > > wrote: > > > > On Tue, May 21, 2024 at 11:36 PM David Malcolm wrote: > >> > >> On Tue, 2024-05-21 at 15:13 +, Qing Zhao wrote: > >>> Thanks for the comments and suggestions. > >>> >

[PATCH] tree-optimization/115199 - fix PTA constraint processing for LHS

When processing a = X constraint we treat it as *ANYTHING = X during constraint processing but then end up recording it as = X anyway, breaking constraint graph building. This is because we only update the local copy of the LHS and not the constraint itself. Bootstrap and regtest running on

[PATCH] tree-optimization/115138 - ptr-vs-ptr and FUNCTION_DECLs

I failed to realize we do not represent FUNCTION_DECLs or LABEL_DECLs in vars explicitly and thus have to compare pt.vars_contains_nonlocal. Bootstrapped and tested with bootstrap-O3 and D to verify the comparison fail is fixed. I'm now doing a regular bootstrap and regtest with the volatile fix

RE: [PATCH v2] Match: Support __builtin_add_overflow branch form for unsigned SAT_ADD

I have a try to convert the PHI from Part-A to Part-B, aka PHI to _2 = phi_cond ? _1 : 255. And then we can do the matching on COND_EXPR in the underlying widen-mul pass. Unfortunately, meet some ICE when verify_gimple_phi in sccopy1 pass => sat_add.c:66:1: internal compiler error: tree check:

[PATCH] RISC-V: Fix missing boolean_expression in zmmul extension

Missing boolean_expression TARGET_ZMMUL in riscv_rtx_costs() casuse different instructions when multiplying an integer with a constant. ( https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1482 ) int foo(int *ib) { *ib = *ib * 33938; return 0; } rv64im: lw a4,0(a1)

RE: [PATCH] [tree-optimization/110279] fix testcase pr110279-1.c

> -Original Message- > From: Jeff Law > Sent: Wednesday, May 22, 2024 11:14 PM > To: Di Zhao OS ; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] [tree-optimization/110279] fix testcase pr110279-1.c > > > > On 5/22/24 5:46 AM, Di Zhao OS wrote: > > The test case is for targets that

Re: [PATCH] invoke.texi: Clarify -march=lujiazui

Hi Jakub: I think the modified lujiazui description is what actually happens,thanks. BR Mayshao [这封邮件来自外部发件人 谨防风险] Hi! Yesterday I was searching which exact CPUs are affected by the PR114576 wrong-code issue and went from the PTA_* bitmasks in GCC, so arrived at the goldmont,

Re: [PATCH v1 2/6] Extract ix86 dllimport implementation to mingw

On Thu, May 23, 2024 at 10:35 AM Uros Bizjak wrote: > > On Wed, May 22, 2024 at 4:32 PM Evgeny Karpov > wrote: > > > > Wednesday, May 22, 2024 1:06 PM > > Richard Sandiford wrote: > > > > > This looks good to me apart from a couple of very minor comments below, > > > but > > > please get

Re: [PATCH 2/3] [APX CCMP] Adjust startegy for selecting ccmp candidates

Gently ping for this :) Hi Richard, Is it OK to adopt the ccmp change? Or did you know who can help to review this part? Thanks. Hongyu Wang 于2024年5月15日周三 16:25写道： > > CC'd Richard for ccmp part as previously it is added only for aarch64. > The original logic will not interrupted since if >

Re: [PATCH v1 2/6] Extract ix86 dllimport implementation to mingw

On Wed, May 22, 2024 at 4:32 PM Evgeny Karpov wrote: > > Wednesday, May 22, 2024 1:06 PM > Richard Sandiford wrote: > > > This looks good to me apart from a couple of very minor comments below, but > > please get approval from the x86 maintainers as well. In particular, they > > might > >

[PATCH 2/2] arm: Add support for MVE Tail-Predicated Low Overhead Loops

This patch adds support for MVE Tail-Predicated Low Overhead Loops by using the doloop funcitonality added to support predicated vectorized hardware loops. gcc/ChangeLog: * config/arm/arm-protos.h (arm_target_bb_ok_for_lob): Change declaration to pass basic_block.

[PATCH 1/2] doloop: Add support for predicated vectorized loops

This patch adds support in the target agnostic doloop pass for the detection of predicated vectorized hardware loops. Arm is currently the only target that will make use of this feature. gcc/ChangeLog: * df-core.cc (df_bb_regno_only_def_find): New helper function. * df.h

[PATCH 0/2] arm, doloop: Add support for MVE Tail-Predicated Low Overhead Loops

Hi, We held these two patches back in stage 4 because they touched target-agnostic code, though I am quite confident they will not affect other targets. Given stage one has reopened, I am reposting them, I rebased them but they seem to apply cleanly on trunk. OK for trunk? Andre Vieira

  1   2   >