git gcc-commit-mklog doesn't extract PR number to ChangeLog

Hi, I noticed that the "git gcc-commit-mklog" command doesn't extract PR number from title to ChangeLog automatically, then the committed patch doesn't update the related bugzilla PR website after check in the patch? Martin, what's your opinion about this since you are much familar about this?

[PATCH] c++: Extend std::is_constant_evaluated in if warning [PR100995]

Jakub pointed me at which shows that our existing warning could be extended to handle more cases. This patch implements that. A minor annoyance was handling macros, in libstdc++ we have reference

Re: [PATCH v4 2/2] x86: Add vec_duplicate expander

On Wed, Jun 9, 2021 at 4:39 PM H.J. Lu wrote: > > 1. Update vec_duplicate to allow to fail so that backend can only allow > broadcasting an integer constant to a vector when broadcast instruction > is available. This can be used by memset expander to avoid vec_duplicate > when loading from

[PATCH v4 1/2] x86: Convert CONST_WIDE_INT/CONST_VECTOR to broadcast

1. Update move expanders to convert the CONST_WIDE_INT and CONST_VECTO operands to vector broadcast from an integer with AVX2. 2. Add ix86_gen_scratch_sse_rtx to return a scratch SSE register which won't increase stack alignment requirement and blocks transformation by the combine pass. A small

[PATCH v4 0/2] x86: Convert CONST_WIDE_INT/CONST_VECTOR to broadcast

1. Update move expanders to convert the CONST_WIDE_INT and CONST_VECTO operands to vector broadcast from an integer with AVX2. 2. Add ix86_gen_scratch_sse_rtx to return a scratch SSE register which won't increase stack alignment requirement and blocks transformation by the combine pass. A small

[PATCH v4 2/2] x86: Add vec_duplicate expander

1. Update vec_duplicate to allow to fail so that backend can only allow broadcasting an integer constant to a vector when broadcast instruction is available. This can be used by memset expander to avoid vec_duplicate when loading from constant pool is more efficient. 2. Add vec_duplicate expander

Re: [PATCH v3 1/2] x86: Convert CONST_WIDE_INT/CONST_VECTOR to broadcast

On Wed, Jun 9, 2021 at 12:44 AM Uros Bizjak wrote: > > [For some reason this message didn't reach my gmail account] > > > 1. Update move expanders to convert the CONST_WIDE_INT and CONST_VECTO > > operands to vector broadcast from an integer with AVX2. > > 2. Add ix86_gen_scratch_sse_rtx to

Re: [PATCH v3 2/2] x86: Add vec_duplicate expander

On Tue, Jun 8, 2021 at 11:41 PM Uros Bizjak wrote: > > On Tue, Jun 8, 2021 at 7:59 PM H.J. Lu wrote: > > > > 1. Update vec_duplicate to allow to fail so that backend can only allow > > broadcasting an integer constant to a vector when broadcast instruction > > is available. This can be used by

Re: [PATCH] rs6000: Support more short/char to float conversion

Hi! On Fri, May 07, 2021 at 10:30:38AM +0800, Kewen.Lin wrote: > For some cases that when we load unsigned char/short values from > the appropriate unsigned char/short memories and convert them to > double/single precision floating point value, there would be > implicit conversions to int first.

Re: [r12-1330 Regression] FAIL: libgomp.fortran/pr100981-2.f90 -Os execution test on Linux/x86_64

On Wed, Jun 09, 2021 at 12:08:39PM -0700, sunil.k.pandey via Gcc-patches wrote: > On Linux/x86_64, > > 374f93da97fb0378453d503f3cfea4d7a923a89c is the first bad commit > commit 374f93da97fb0378453d503f3cfea4d7a923a89c > Author: Richard Biener > Date: Wed Jun 9 14:48:35 2021 +0200 > >

[committed] analyzer: make various region_model member functions const

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as 53cb324cb4f9475d4eabcd9f5a858c5edaacc0cf. gcc/analyzer/ChangeLog: * region-model.cc (region_model::get_lvalue_1): Make const. (region_model::get_lvalue): Likewise.

[PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

Dear Fortranners, we should be able to simplify the length of a substring with known constant bounds. The attached patch adds this. Regtested on x86_64-pc-linux-gnu. OK for mainline? Since this should be rather safe, to at least 11-branch? Thanks, Harald Fortran - simplify length of

Re: [PATCH] rs6000: Add new __builtin_vsx_build_pair and __builtin_mma_build_acc built-ins

Hi! On Wed, Jun 09, 2021 at 04:05:37PM -0500, Peter Bergner wrote: > The __builtin_vsx_assemble_pair and __builtin_mma_assemble_acc built-ins > currently assign their first source operand to the first VSX register > in a pair/quad, their second operand to the second register in a pair/quad, >

Re: [patch] Reuse non-gimple_reg variable for inlining

> I'm afraid the inliner would need to prove the to be inlined callee doesn't > modify its own copy of the variable too, because if it modifies it (at least > in C/C++ const can be cast away), then this introduces wrong-code, see > PR100994 for details. Then please remove the TREE_READONLY marker

Re: [PATCH] middle-end/100951 - make sure to generate VECTOR_CST in lowering

On Wed, Jun 9, 2021 at 2:03 PM Jeff Law wrote: > > > > On 6/7/2021 2:33 PM, H.J. Lu via Gcc-patches wrote: > > On Mon, Jun 7, 2021 at 11:10 AM Richard Biener > wrote: > > On Mon, Jun 7, 2021 at 7:59 PM Richard Biener > wrote: > > On Mon, Jun 7, 2021 at 4:19 PM H.J. Lu wrote: > > On Mon, Jun 7,

Re: [PATCH 1/2] c-family: Copy DECL_USER_ALIGN even if DECL_ALIGN is similar.

On 6/9/21 4:47 AM, Robin Dapp wrote: As you say, the logic is convoluted.  Let's simplify it rather than make it more convoluted.  One possibility would be to change || to | toavoid the shortcut, and then bool note = lastalign > curalign; if (note) curalign = lastalign; I went with your

[PATCH] rs6000: Add new __builtin_vsx_build_pair and __builtin_mma_build_acc built-ins

The __builtin_vsx_assemble_pair and __builtin_mma_assemble_acc built-ins currently assign their first source operand to the first VSX register in a pair/quad, their second operand to the second register in a pair/quad, etc. This is not endian friendly and forces the user to generate different

Re: [PATCH] middle-end/100951 - make sure to generate VECTOR_CST in lowering

On 6/7/2021 2:33 PM, H.J. Lu via Gcc-patches wrote: On Mon, Jun 7, 2021 at 11:10 AM Richard Biener wrote: On Mon, Jun 7, 2021 at 7:59 PM Richard Biener wrote: On Mon, Jun 7, 2021 at 4:19 PM H.J. Lu wrote: On Mon, Jun 7, 2021 at 12:12 AM Richard Sandiford wrote: "H.J. Lu" writes:

[committed] libstdc++: Only support atomic_ref::wait tests which are always lockfree

Fixes a regression on arm32 targets. libstdc++/ChangeLog: * testsuite/29_atomics/atomic_ref/wait_notify.cc: Guard test logic with constexpr check for is_always_lock_free. As discussed on IRC. Tested x86_64-pc-linux-gnu, committed to master, backported to releases/gcc-11. ---

Re: [PATCH/RFC] combine: Tweak the condition of last_set invalidation

Hi! On Wed, Dec 16, 2020 at 04:49:49PM +0800, Kewen.Lin wrote: > Currently we have the check: > > if (!insn > || (value && rsp->last_set_table_tick >= label_tick_ebb_start)) > rsp->last_set_invalid = 1; > > which means if we want to record some value for some reg and > this

Re: [PATCH] tree-optimization/97832 - handle associatable chains in SLP discovery

On Wed, 9 Jun 2021 at 18:56, Alex Coplan via Gcc-patches wrote: > > Hi Richi, > > On 09/06/2021 14:42, Richard Biener via Gcc-patches wrote: > > On Mon, May 31, 2021 at 5:00 PM Richard Biener wrote: > > > > > > This makes SLP discovery handle associatable (including mixed > > > plus/minus)

Re: [PATCH] c++: matching deduced template template parameters [PR67829]

On Wed, 9 Jun 2021, Patrick Palka wrote: > During deduction, when the template of a BOUND_TEMPLATE_TEMPLATE_PARM is Ah sorry, this should instead say "when the template of _the argument for_ a BOUND_TEMPLATE_TEMPLATE_PARM is ..." > a template template parameter, we need to consider the >

[PATCH] c++: normalization of non-templated return-type-req [PR100946]

Here the satisfaction cache is conflating the satisfaction value of the two return-type-requirements because the corresponding constrained 'auto's have level 2, but they capture an empty current_template_parms. This ultimately causes the satisfaction cache to think the type constraint doesn't

[PATCH] c++: matching deduced template template parameters [PR67829]

During deduction, when the template of a BOUND_TEMPLATE_TEMPLATE_PARM is a template template parameter, we need to consider the TEMPLATE_TEMPLATE_PARAMETER rather than the TEMPLATE_DECL thereof, because the canonical form of a template template parameter in a template argument list is the

Re: [PATCH] Document that -fno-trampolines is for Ada only [PR100735]

On 6/9/2021 12:15 PM, Thomas Rodgers wrote: On 2021-06-09 09:23, Jeff Law via Gcc-patches wrote: On 5/25/2021 2:23 PM, Paul Eggert wrote: The GCC manual's documentation of -fno-trampolines was apparently written from an Ada point of view. However, when I read it I understandably mistook 

Re: [patch] Reuse non-gimple_reg variable for inlining

On Mon, May 03, 2021 at 10:04:20AM +0200, Eric Botcazou wrote: > Hi, > > when a call to a function is inlined and takes a parameter whose type is not > gimple_reg, a variable is created in the caller to hold a copy of the argument > passed in the call with the following comment: > > /* We

[r12-1330 Regression] FAIL: libgomp.fortran/pr100981-2.f90 -Os execution test on Linux/x86_64

On Linux/x86_64, 374f93da97fb0378453d503f3cfea4d7a923a89c is the first bad commit commit 374f93da97fb0378453d503f3cfea4d7a923a89c Author: Richard Biener Date: Wed Jun 9 14:48:35 2021 +0200 tree-optimization/100981 - fix SLP patterns involving reductions caused FAIL:

Re: [PATCH] Implement a context aware points-to analyzer for use in evrp.

On 6/9/21 7:32 AM, Richard Biener wrote: On Tue, Jun 8, 2021 at 4:31 PM Andrew MacLeod wrote: an iteration causes a relation to become "better" it should be updated. do a very simplistic thing when trying to simplify downstream conditions based on earlier ones, abusing their

Re: [PATCH] Implement a context aware points-to analyzer for use in evrp.

On 6/9/21 12:50 PM, Aldy Hernandez wrote: On 6/9/21 7:10 PM, Martin Sebor wrote: On 6/7/21 12:29 PM, Aldy Hernandez via Gcc-patches wrote: Mostly just a question of the type choices in the implementation of the ssa_equiv_stack class: m_stack is an auto_vec while m_replacements is a plain

[PATCH] Update doc/tm.texi.in to fix commit 4a0c4eaea32

PR other/100735 * doc/tm.texi.in (Trampolines): Add a missing blank line. --- gcc/doc/tm.texi.in | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in index 20501607716..33532f092b6 100644 --- a/gcc/doc/tm.texi.in +++ b/gcc/doc/tm.texi.in @@

Re: [PATCH] Document that -fno-trampolines is for Ada only [PR100735]

On Wed, Jun 9, 2021 at 11:15 AM Thomas Rodgers wrote: > > On 2021-06-09 09:23, Jeff Law via Gcc-patches wrote: > > > On 5/25/2021 2:23 PM, Paul Eggert wrote: > > > >> The GCC manual's documentation of -fno-trampolines was apparently > >> written from an Ada point of view. However, when I read it

Re: [PATCH] Implement a context aware points-to analyzer for use in evrp.

On 6/9/21 7:10 PM, Martin Sebor wrote: On 6/7/21 12:29 PM, Aldy Hernandez via Gcc-patches wrote: Mostly just a question of the type choices in the implementation of the ssa_equiv_stack class: m_stack is an auto_vec while m_replacements is a plain array.  I'd expect both to be the same

Re: [PATCH] Document that -fno-trampolines is for Ada only [PR100735]

Jeff et. al. > On 9 Jun 2021, at 17:23, Jeff Law via Gcc-patches > wrote: > On 5/25/2021 2:23 PM, Paul Eggert wrote: >> The GCC manual's documentation of -fno-trampolines was apparently >> written from an Ada point of view. However, when I read it I >> understandably mistook it to say that

Re: [PATCH] Document that -fno-trampolines is for Ada only [PR100735]

On 2021-06-09 09:23, Jeff Law via Gcc-patches wrote: On 5/25/2021 2:23 PM, Paul Eggert wrote: The GCC manual's documentation of -fno-trampolines was apparently written from an Ada point of view. However, when I read it I understandably mistook it to say that -fno-trampolines also works for C,

[committed] d: TypeInfo error when using slice copy on Structs (PR100964)

Hi, This patch fixes a compiler error when using a slice copy on structs. Known limitation: does not work for struct with postblit or dtor. Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, committed to mainline, and backported to the gcc-9, gcc-10, and gcc-11 release branches.

[committed] d: Respect explicit align(N) type alignment (PR100935)

Hi, This patch fixes the .alignof property to report the correct alignment if an explicit one was given for the type. It was previously the natural type alignment, defined as the maximum of the field alignments for an aggregate. Make sure an explicit align(N) overrides it. Bootstrapped and

Re: [PATCH] Implement a context aware points-to analyzer for use in evrp.

On 6/7/21 12:29 PM, Aldy Hernandez via Gcc-patches wrote: On 6/7/21 3:30 PM, Richard Biener wrote: On Mon, Jun 7, 2021 at 12:10 PM Aldy Hernandez via Gcc-patches wrote: The substitute_and_fold_engine which evrp uses is expecting symbolics from value_of_expr / value_on_edge / etc, which

RE: [PATCH] PR middle-end/53267: Constant fold BUILT_IN_FMOD.

Hi Jeff (and Richard), Many thanks to you both. Fingers-crossed my write-access (after approval) still works (I think it's just maintainer status that I've lost over time), but finding time to contribute is getting much harder, so my response time is much slower than it was a decade ago.

Re: [PATCH] tree-optimization/97832 - handle associatable chains in SLP discovery

Hi Richi, On 09/06/2021 14:42, Richard Biener via Gcc-patches wrote: > On Mon, May 31, 2021 at 5:00 PM Richard Biener wrote: > > > > This makes SLP discovery handle associatable (including mixed > > plus/minus) chains better by swapping operands across the whole > > chain. To work this adds

Re: [PATCH v2] rs6000: Support doubleword swaps removal in rot64 load store [PR100085]

On Wed, Jun 09, 2021 at 11:06:31AM +0800, Xionghu Luo wrote: > On 2021/6/9 05:07, Segher Boessenkool wrote: > >> -/* { dg-final { scan-assembler "lxvd2x 34" } } */ > >> -/* { dg-final { scan-assembler "stxvd2x 34" } } */ > >> +/* { dg-final { scan-assembler "lvx 2" } } */ > >> +/* { dg-final {

Re: [PATCH] rs6000: Support doubleword swaps removal in rot64 load store [PR100085]

On Wed, Jun 09, 2021 at 11:20:20AM +0800, Xionghu Luo wrote: > On 2021/6/9 04:11, Segher Boessenkool wrote: > > On Fri, Jun 04, 2021 at 09:40:58AM +0800, Xionghu Luo wrote: > rejecting combination of insns 6 and 7 > original costs 4 + 4 = 8 > replacement cost 12 > >>> > >>> So what

Re: [PATCH] Document that -fno-trampolines is for Ada only [PR100735]

On 5/25/2021 2:23 PM, Paul Eggert wrote: The GCC manual's documentation of -fno-trampolines was apparently written from an Ada point of view. However, when I read it I understandably mistook it to say that -fno-trampolines also works for C, C++, etc. It doesn't: it is silently ignored for

Re: [PATCH] Introduce -Wcoverage-invalid-line-number

On 6/1/2021 8:09 AM, Martin Liška wrote: Hello. As seen in the PR, one can easily corrupt line number information and we can end up with a function that ends before it starts ;) I'm adding a new warning for that instead of the ICE. Patch can bootstrap on x86_64-linux-gnu and survives

Re: [PATCH] libgcc libiberty: optimize and modernize standard string and memory functions

On 6/3/2021 12:51 PM, Seija K. via Gcc-patches wrote: This patch optimizes and simplifies many of the standard string functions. Since C99, some of the standard string functions have been changed to use the restrict modifier. diff --git a/libgcc/memcmp.c b/libgcc/memcmp.c index

Re: [PATCH] arm: Auto-vectorization for MVE and Neon: vhadd/vrhadd

On Wed, 9 Jun 2021 at 17:39, Richard Sandiford wrote: > > Christophe Lyon writes: > > This patch adds support for auto-vectorization of average value > > computation using vhadd or vrhadd, for both MVE and Neon. > > > > The patch adds the needed [u]avg3_[floor|ceil] patterns to > >

Re: [PATCH 1/2] arm: Auto-vectorization for MVE: vclz

Christophe Lyon writes: > On Tue, 8 Jun 2021 at 13:58, Richard Sandiford > wrote: >> >> Christophe Lyon writes: >> > This patch adds support for auto-vectorization of clz for MVE. >> > >> > It does so by removing the unspec from mve_vclzq_ and uses >> > 'clz' instead. It moves to neon_vclz

PING [PATCH] teach compute_objsize about placement new (PR 100876)

Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571777.html On 6/2/21 3:40 PM, Martin Sebor wrote: The two forms of placement operator new defined in return their pointer argument and may not be displaced by user-defined functions. But because they are ordinary (not built-in)

Re: [PATCH 1/2] arm: Auto-vectorization for MVE: vclz

On Tue, 8 Jun 2021 at 13:58, Richard Sandiford wrote: > > Christophe Lyon writes: > > This patch adds support for auto-vectorization of clz for MVE. > > > > It does so by removing the unspec from mve_vclzq_ and uses > > 'clz' instead. It moves to neon_vclz expander from neon.md to > >

Re: [PATCH] arm: Auto-vectorization for MVE and Neon: vhadd/vrhadd

Christophe Lyon writes: > This patch adds support for auto-vectorization of average value > computation using vhadd or vrhadd, for both MVE and Neon. > > The patch adds the needed [u]avg3_[floor|ceil] patterns to > vec-common.md, I'm not sure how to factorize them without introducing > an unspec

Re: [PATCH] libgomp: Compile tests with -march=i486 if needed

On 6/6/2021 7:03 AM, H.J. Lu via Gcc-patches wrote: Don't add -march=i486 if atomic compare-and-swap is supported on 'int'. This fixes libgomp tests with "-march=x86-64 -m32 -fcf-protection". * testsuite/lib/libgomp.exp (libgomp_init): Don't add -march=i486 if atomic

Re: [PATCH] doc/typo: mthread -> mthreads

On 6/7/2021 8:38 PM, imba-tjd via Gcc-patches wrote: unrecognized command line option '-mthread'; did you mean '-mthreads'? --- gcc/doc/invoke.texi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Thanks.  Installed on the trunk. jeff

Re: [PATCH] PR middle-end/53267: Constant fold BUILT_IN_FMOD.

On 6/9/2021 4:51 AM, Richard Biener via Gcc-patches wrote: On Tue, Jun 8, 2021 at 9:36 PM Roger Sayle wrote: Here's a three line patch to implement constant folding for fmod, fmodf and fmodl, which resolves an enhancement request from 2012. The following patch has been tested on

RE: [PATCH] tree-optimization/100981 - fix SLP patterns involving reductions

Hi Richi, > -Original Message- > From: Gcc-patches bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of Richard > Biener > Sent: Wednesday, June 9, 2021 1:53 PM > To: gcc-patches@gcc.gnu.org > Cc: Richard Sandiford > Subject: [PATCH] tree-optimization/100981 - fix SLP patterns

Re: [PATCH] PR tree-optimization/100781 - Do not calculate new values when evaluating a debug, statement.

On 6/9/21 7:48 AM, Richard Biener wrote: On Tue, Jun 8, 2021 at 4:48 PM Andrew MacLeod wrote: Richard. Andrew OK, so this would be the simple way I'd tackle this in gcc11. This should be quite safe. Just treat debug_stmts as if they are not stmts.. and make a global query. EVRP will

Re: [PATCH] s390: Add more vcond_mask patterns.

On 6/9/21 2:47 PM, Robin Dapp wrote: >> I think the real problem is the expander name. That's why it could not be >> found by optab. The second >> mode needs to be the int vector mode of op3. With that change the testcases >> work as expected: >> >> diff --git a/gcc/config/s390/vector.md

Re: [PATCH] libstdc++: Fix Wrong param type in :atomic_ref<_Tp*>::wait [PR100889]

For other tests that don't link to libatomic we use if-constexpr to limit which types we test e.g. --- a/libstdc++-v3/testsuite/29_atomics/atomic_ref/wait_notify.cc +++ b/libstdc++-v3/testsuite/29_atomics/atomic_ref/wait_notify.cc @@ -33,14 +33,17 @@ template S aa{ va }; S bb{ vb };

Re: [PATCH] arm: Auto-vectorization for MVE and Neon: vhadd/vrhadd

On Tue, 8 Jun 2021 at 13:50, Richard Sandiford wrote: > > Christophe Lyon writes: > > On Wed, 2 Jun 2021 at 20:19, Richard Sandiford > > wrote: > >> > >> Christophe Lyon writes: > >> > This patch adds support for auto-vectorization of average value > >> > computation using vhadd or vrhadd, for

Re: [PATCH 1/2] arm: Fix vcond_mask expander for MVE (PR target/100757)

Christophe Lyon writes: > The problem in this PR is that we call VPSEL with a mask of vector > type instead of HImode. This happens because operand 3 in vcond_mask > is the pre-computed vector comparison and has vector type. The fix is > to transfer this value to VPR.P0 by comparing operand 3

Re: [committed] analyzer: bitfield fixes [PR99212]

On Wed, 2021-06-09 at 16:17 +0200, Christophe Lyon wrote: > On Tue, 8 Jun 2021 at 21:34, David Malcolm via Gcc-patches > wrote: > > > > This patch verifies the previous fix for bitfield sizes by > > implementing > > enough support for bitfields in the analyzer to get the test cases > > to pass.

Re: [PATCH] Use range based loops to iterate over vec<> in various places

On 6/8/21 6:48 PM, Trevor Saunders wrote: Hello, This makes things a good bit shorter, and reduces complexity by removing a bunch of index variables. Very nice cleanup! Thank you! Martin bootstrapped and regtested on x86_64-linux-gnu, ok? Trev gcc/analyzer/ChangeLog: *

Re: [PATCH] libstdc++: Fix Wrong param type in :atomic_ref<_Tp*>::wait [PR100889]

Pretty sure I know this is, I'll work on a fix today. On Wed, Jun 9, 2021 at 7:30 AM Christophe Lyon wrote: > Hi, > > > On Wed, 9 Jun 2021 at 01:05, Thomas Rodgers via Gcc-patches > wrote: > > > > Tested x86_64-pc-linux-gnu, committed to master, backported to > > releases/gcc-11. > > > > On

Re: [PATCH] arc: Add --with-fpu support for ARCv2 cpus

On 6/9/2021 6:26 AM, Bernhard Reutner-Fischer wrote: On Wed, 9 Jun 2021 14:35:01 +0300 Claudiu Zissulescu wrote: ISTM you only set the expected flags in the switch so i would have set only that variable and have grepped only once after the switch for brevity. ARC has various FPU

[PATCH] gcc/configure.ac: fix register issue for global_load assembler functions

This patch fixes an issue with global_load assembler functions leading to a "invalid operand for instruction" error since in different LLVM versions those functions use either one or two registers. In this patch a compatibility check is added to the configure.ac. Marcel - Mentor

[PATCH][RFC] Vectorize BB reductions

This adds a simple reduction vectorization capability to the non-loop vectorizer. Simple meaning it lacks any of the fancy ways to generate the reduction epilogue but only supports those we can handle via a direct internal function reducing a vector to a scalar. One of the main reasons is to

Re: [PATCH,rs6000] Fix p10 fusion test cases for -m32

On Wed, May 26, 2021 at 04:53:24PM -0500, Aaron Sawdey wrote: > > The counts of fusion insns are slightly different for 32-bit compiles > > so we need different scan-assembler-times counts for 32 and 64 bit > > in the test cases for p10 fusion. Have you checked all of these actually make sense?

Re: [PATCH] libstdc++: Fix Wrong param type in :atomic_ref<_Tp*>::wait [PR100889]

Hi, On Wed, 9 Jun 2021 at 01:05, Thomas Rodgers via Gcc-patches wrote: > > Tested x86_64-pc-linux-gnu, committed to master, backported to > releases/gcc-11. > > On Tue, Jun 8, 2021 at 8:44 AM Jonathan Wakely wrote: > > > On Tue, 8 Jun 2021 at 01:29, Thomas Rodgers wrote: > > > >> This time

Re: [committed] analyzer: bitfield fixes [PR99212]

On Tue, 8 Jun 2021 at 21:34, David Malcolm via Gcc-patches wrote: > > This patch verifies the previous fix for bitfield sizes by implementing > enough support for bitfields in the analyzer to get the test cases to pass. > > The patch implements support in the analyzer for reading from a >

Re: [PATCH 11/11] libstdc++: Fix ODR issues with different -m flags

On Wed, Jun 9, 2021 at 2:53 PM Matthias Kretz wrote: > > On Wednesday, 9 June 2021 14:22:00 CEST Richard Biener wrote: > > On Tue, Jun 8, 2021 at 2:23 PM Matthias Kretz wrote: > > > From: Matthias Kretz > > > > > > Explicitly support use of the stdx::simd implementation in situations > > >

Re: [PATCH v3 1/2] x86: Convert CONST_WIDE_INT/CONST_VECTOR to broadcast

On Wed, Jun 9, 2021 at 1:17 AM Hongtao Liu wrote: > > On Wed, Jun 9, 2021 at 2:02 AM H.J. Lu via Gcc-patches > wrote: > > > > 1. Update move expanders to convert the CONST_WIDE_INT and CONST_VECTO > > operands to vector broadcast from an integer with AVX2. > > 2. Add ix86_gen_scratch_sse_rtx to

Re: [PATCH 02/57] Support scanning of build-time GC roots in gengtype

On 6/9/21 5:54 AM, Richard Biener wrote: On Wed, Jun 9, 2021 at 12:53 PM Richard Biener wrote: On Tue, Jun 8, 2021 at 10:45 PM Bill Schmidt wrote: On 6/7/21 12:48 PM, Bill Schmidt wrote: On 6/7/21 12:45 PM, Richard Biener wrote: On Mon, Jun 7, 2021 at 5:38 PM Bill Schmidt wrote: On

Re: [PATCH 11/11] libstdc++: Fix ODR issues with different -m flags

On Wednesday, 9 June 2021 14:22:00 CEST Richard Biener wrote: > On Tue, Jun 8, 2021 at 2:23 PM Matthias Kretz wrote: > > From: Matthias Kretz > > > > Explicitly support use of the stdx::simd implementation in situations > > where the user links TUs that were compiled with different -m flags. In

[PATCH] tree-optimization/100981 - fix SLP patterns involving reductions

The following fixes the SLP FMA patterns to preserve reduction info and the reduction vectorization to consider internal function call defs for the reduction stmt. Bootstrap & regtest running on x86_64-unknown-linux-gnu, Andre verified we're not turning an ICE into a wrong-code bug (.COMPLEX_MUL

Re: [PATCH] s390: Add more vcond_mask patterns.

I think the real problem is the expander name. That's why it could not be found by optab. The second mode needs to be the int vector mode of op3. With that change the testcases work as expected: diff --git a/gcc/config/s390/vector.md b/gcc/config/s390/vector.md index c80d582a300d..ab605b3d2cf3

Re: [PATCH] tree-optimization/97832 - handle associatable chains in SLP discovery

On Mon, May 31, 2021 at 5:00 PM Richard Biener wrote: > > This makes SLP discovery handle associatable (including mixed > plus/minus) chains better by swapping operands across the whole > chain. To work this adds caching of the 'matches' lanes for > failed SLP discovery attempts, thereby fixing

Re: [PATCH] testsuite: Add vect_floatint_cvt to gcc.dg/vect/pr56541.c

gcc/testsuite/ChangeLog:     * gcc.dg/vect/pr56541.c: Add vect_floatint_cvt. OK.  I'd tend to use XFAIL for a compiler bug that we haven't fixed.  In this case the target doesn't support what the test is trying to do.  So skipping the test in one manner or another seems better. Just

Re: [PATCH] arc: Add --with-fpu support for ARCv2 cpus

On Wed, 9 Jun 2021 14:35:01 +0300 Claudiu Zissulescu wrote: > > ISTM you only set the expected flags in the switch so i would have > > set only that variable and have grepped only once after the switch for > > brevity. > > ARC has various FPU extensions, some of them are common to EM and HS

Re: [PATCH 11/11] libstdc++: Fix ODR issues with different -m flags

On Tue, Jun 8, 2021 at 2:23 PM Matthias Kretz wrote: > > > From: Matthias Kretz > > Explicitly support use of the stdx::simd implementation in situations > where the user links TUs that were compiled with different -m flags. In > general, this is always a (quasi) ODR violation for inline

Re: [PATCH 0.5/2] ipa-sra: Restructure how cloning and call redirection communicate (PR 93385)

Hi Honza, I'd like to ping this patch. I know it is big but I do believe it makes the management of information passed from clone materialization to edge redirection much more straightforward. And I need it to fix PR 93385 with a follow-up that has already been approved by Richi. A recently

[Patch ]Fortran/OpenMP: Extend defaultmap clause for OpenMP 5 [PR92568]

This patch add's OpenMP 5.1's defaultmap extensions to Fortran. There is one odd thing, integer :: ii, it target :: it both count as nonallocatable, nonpointer scalars (i.e. category 'scalar'). But with implicit mapping (and 'defaultmap(default)'), 'it' is mapped tofrom due to the TARGET

Re: [PATCH v2] Always enable DT_INIT_ARRAY/DT_FINI_ARRAY on Linux

On Wed, Jun 9, 2021 at 2:05 PM H.J. Lu wrote: > > On Wed, Jun 9, 2021 at 4:00 AM Richard Biener > wrote: > > > > On Wed, Jun 9, 2021 at 1:13 AM H.J. Lu via Gcc-patches > > wrote: > > > > > > DT_INIT_ARRAY/DT_FINI_ARRAY support was added to glibc by > > > > > > commit

[PATCH v2] Always enable DT_INIT_ARRAY/DT_FINI_ARRAY on Linux

On Wed, Jun 9, 2021 at 4:00 AM Richard Biener wrote: > > On Wed, Jun 9, 2021 at 1:13 AM H.J. Lu via Gcc-patches > wrote: > > > > DT_INIT_ARRAY/DT_FINI_ARRAY support was added to glibc by > > > > commit fcf70d4114db9ff7923f5dfeb3fea6e2d623e5c2 > > Author: Ulrich Drepper > > Date: Sat Jul 24

Re: [PATCH] rs6000: Remove unspecs for vec_mrghl[bhw]

Hi! On Wed, Jun 09, 2021 at 04:03:43PM +0800, Xionghu Luo wrote: > >>--- a/gcc/testsuite/gcc.target/powerpc/builtins-1.c > >>+++ b/gcc/testsuite/gcc.target/powerpc/builtins-1.c > >>@@ -317,10 +317,10 @@ int main () > >> /* { dg-final { scan-assembler-times "vctuxs" 2 } } */ > >> > >> /* {

Re: [PATCH] Use range based loops to iterate over vec<> in various places

On Wed, Jun 9, 2021 at 1:32 PM Trevor Saunders wrote: > > On Wed, Jun 09, 2021 at 01:06:44PM +0200, Richard Biener wrote: > > On Wed, Jun 9, 2021 at 2:48 AM Trevor Saunders > > wrote: > > > > > > Hello, > > > > > > This makes things a good bit shorter, and reduces complexity by removing > > > a

Re: [PATCH] PR tree-optimization/100781 - Do not calculate new values when evaluating a debug, statement.

On Tue, Jun 8, 2021 at 4:48 PM Andrew MacLeod wrote: > > On 6/2/21 3:29 AM, Richard Biener wrote: > > On Tue, Jun 1, 2021 at 4:24 PM Andrew MacLeod wrote: > >> On 6/1/21 3:34 AM, Richard Biener wrote: > >>> On Tue, Jun 1, 2021 at 3:38 AM Andrew MacLeod via Gcc-patches > >>> wrote: > An

[committed] libstdc++: Fix constraint on std::optional assignment [PR 100982]

libstdc++-v3/ChangeLog: PR libstdc++/100982 * include/std/optional (optional::operator=(const optional&)): Fix value category used in is_assignable check. * testsuite/20_util/optional/assignment/100982.cc: New test. Tested powerpc64le-linux. Committed to trunk.

[PATCH][pushed] docs: add missing @headitem in Intrinsic Procedures

Pushed as obvious. Martin gcc/fortran/ChangeLog: * intrinsic.texi: Add missing @headitem to tables with a header. --- gcc/fortran/intrinsic.texi | 144 ++--- 1 file changed, 72 insertions(+), 72 deletions(-) diff --git a/gcc/fortran/intrinsic.texi

Re: [PATCH] arc: Add --with-fpu support for ARCv2 cpus

Hi, I would have written [[:space:]]* instead of [[:space:]]+ to handle potentially missing space, at least after the comma but also before the comma to avoid surprises for new names in the future. Furthermore | alone would be [[:blank:]]* but as you prefer. grep ... > /dev/null would be grep

Re: [PATCH] Implement a context aware points-to analyzer for use in evrp.

On Tue, Jun 8, 2021 at 4:31 PM Andrew MacLeod wrote: > > On 6/8/21 3:26 AM, Richard Biener wrote: > > On Mon, Jun 7, 2021 at 9:20 PM Andrew MacLeod wrote: > >> > >> I don't think this is actually doing the propagation though... It tracks > >> that a_2 currently points to and returns that to

Re: [PATCH] Use range based loops to iterate over vec<> in various places

On Wed, Jun 09, 2021 at 01:06:44PM +0200, Richard Biener wrote: > On Wed, Jun 9, 2021 at 2:48 AM Trevor Saunders wrote: > > > > Hello, > > > > This makes things a good bit shorter, and reduces complexity by removing > > a bunch of index variables. > > > > bootstrapped and regtested on

Re: [PATCH V3] Split loop for NE condition.

On 2021-06-09 17:42, guojiufu via Gcc-patches wrote: On 2021-06-08 18:13, Richard Biener wrote: On Fri, 4 Jun 2021, Jiufu Guo wrote: cut... + gcond *cond = as_a (last); + enum tree_code code = gimple_cond_code (cond); + if (!(code == NE_EXPR + || (code == EQ_EXPR &&

Re: [PATCH 2/2] Disallow pointer and offset types on some gimple

On Wed, Jun 9, 2021 at 3:33 AM apinski--- via Gcc-patches wrote: > > From: Andrew Pinski > > While debugging PR 100925, I found that the gimple verifiers > don't reject NEGATE on pointer or offset type. > This patch adds the check on some unary and binary gimple which > should not have operated

[PATCH] aix: add Power10 flag in ASM_CPU_SPEC

Changelog: 2021-06-09 Clément Chigot * config/rs6000/aix71.h (ASM_CPU_SPEC): Add entry for Power10. * config/rs6000/aix72.h (ASM_CPU_SPEC): Likewise. 0001-aix-add-Power10-flag-in-ASM_CPU_SPEC.patch Description: 0001-aix-add-Power10-flag-in-ASM_CPU_SPEC.patch

Re: [PATCH 1/2] Fix PR 100925: Limit some a?CST1:CST2 optimizations to intergal types only

On Wed, Jun 9, 2021 at 3:32 AM apinski--- via Gcc-patches wrote: > > From: Andrew Pinski > > The problem here is with offset (and pointer) types is we produce > a negative expression when this optimization hits. > It is easier to disable this optimization for all non-integeral types > instead of

[PATCH] Simplify vect_is_simple_use

This simplifies vect_is_simple_use to always get the def-type from the stmt_info instead of singleing out some gimple stmt kinds. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2021-06-09 Richard Biener * tree-vect-stmts.c (vect_is_simple_use): Always get dt

Re: [PATCH] Use range based loops to iterate over vec<> in various places

On Wed, Jun 9, 2021 at 2:48 AM Trevor Saunders wrote: > > Hello, > > This makes things a good bit shorter, and reduces complexity by removing > a bunch of index variables. > > bootstrapped and regtested on x86_64-linux-gnu, ok? I'd call the cases where you are able to remove the iterator

Re: [PATCH] Always enable DT_INIT_ARRAY/DT_FINI_ARRAY on Linux

On Wed, Jun 9, 2021 at 1:13 AM H.J. Lu via Gcc-patches wrote: > > DT_INIT_ARRAY/DT_FINI_ARRAY support was added to glibc by > > commit fcf70d4114db9ff7923f5dfeb3fea6e2d623e5c2 > Author: Ulrich Drepper > Date: Sat Jul 24 19:45:13 1999 + > > Update. > > 1999-07-24 Ulrich Drepper >

Re: [PATCH 02/57] Support scanning of build-time GC roots in gengtype

On Wed, Jun 9, 2021 at 12:53 PM Richard Biener wrote: > > On Tue, Jun 8, 2021 at 10:45 PM Bill Schmidt wrote: > > > > On 6/7/21 12:48 PM, Bill Schmidt wrote: > > > On 6/7/21 12:45 PM, Richard Biener wrote: > > >> On Mon, Jun 7, 2021 at 5:38 PM Bill Schmidt > > >> wrote: > > >>> On 6/7/21 8:36

Re: [PATCH 02/57] Support scanning of build-time GC roots in gengtype

On Tue, Jun 8, 2021 at 10:45 PM Bill Schmidt wrote: > > On 6/7/21 12:48 PM, Bill Schmidt wrote: > > On 6/7/21 12:45 PM, Richard Biener wrote: > >> On Mon, Jun 7, 2021 at 5:38 PM Bill Schmidt > >> wrote: > >>> On 6/7/21 8:36 AM, Richard Biener wrote: > Some maybe obvious issue - what about

Re: [PATCH] PR middle-end/53267: Constant fold BUILT_IN_FMOD.

On Tue, Jun 8, 2021 at 9:36 PM Roger Sayle wrote: > > > Here's a three line patch to implement constant folding for fmod, > fmodf and fmodl, which resolves an enhancement request from 2012. > > The following patch has been tested on x86_64-pc-linux-gnu with > a make bootstrap and make -k check

Re: [ARM] PR98435: Missed optimization in expanding vector constructor

On Fri, 4 Jun 2021 at 13:15, Christophe Lyon wrote: > > On Fri, 4 Jun 2021 at 09:27, Prathamesh Kulkarni via Gcc-patches > wrote: > > > > Hi, > > As mentioned in PR, for the following test-case: > > > > #include > > > > bfloat16x4_t f1 (bfloat16_t a) > > { > > return vdup_n_bf16 (a); > > } >

  1   2   >