[PATCH v4 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

From: Tsukasa OI 'XVentanaCondOps' is a vendor extension from Ventana Micro Systems containing two instructions for conditional move and will be supported on their Veyron V1 CPU. And most notably (for historical reasons), 'XVentanaCondOps' and the standard 'Zicond' extension are functionally

[PATCH v4 0/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

PATCH v1: PATCH v2: PATCH v3: Changes: v1 -> v2 * Removed bogus opt2 pattern as pointed

Re: [PATCH] xtensa: Optimize boolean evaluation when SImode EQ/NE to zero if TARGET_MINMAX

On 2023/09/06 8:01, Max Filippov wrote: > Hi Suwa-san, Hi! > > On Tue, Sep 5, 2023 at 2:29 AM Takayuki 'January June' Suwa > wrote: >> >> This patch optimizes the boolean evaluation for equality to 0 in SImode >> using the MINU (Minimum Value Unsigned) machine instruction available >> when

Re: [PATCH] RISC-V: Add conditional sqrt autovec pattern

On 2023/9/6 8:31, Jeff Law wrote: On 9/3/23 22:49, Lehua Ding wrote: This patch adds a combined pattern for combining vfsqrt.v and vcond_mask. gcc/ChangeLog: * config/riscv/autovec-opt.md (*cond_): Add sqrt + vcond_mask combine pattern. * config/riscv/autovec.md (2):

[Bug c++/111301] misleading messages about missing "inline"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111301 --- Comment #1 from Andrew Pinski --- Note the float case is actually supposed to be rejected without a const for the same reason as the int ... GCC had an extension which allowed `const static float` being initialized `in-class

[Bug c++/111301] New: misleading messages about missing "inline"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111301 Bug ID: 111301 Summary: misleading messages about missing "inline" Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

Re: [PATCH v3] RISC-V:Optimize the MASK opt generation

Reading the manual again, it seems I missed something in the manual before, the MASK syntax already says we can specify Var to select the variable other than target_flags, but I tried that not work when we only declare Mask with Var (e.g. "Mask(VECTOR_ELEN_32) Var(riscv_vector_elen_flags)" still

[pushed] c++: [[no_unique_address]] and cv-qualified type

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- We were checking for overlap using same_type_p and therefore allocating two Empty subobjects at the same offset because one was cv-qualified. This gives the warning at the location of the class name rather than the member declaration, but

Re: [PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

On Tue, 05 Sep 2023 20:07:16 PDT (-0700), gcc-patches@gcc.gnu.org wrote: On 9/5/23 20:33, Tsukasa OI wrote: Internally we have this as: (TARGET_ZICOND || TARGET_XVENTANACONDOPS) I don't really care, so I'm happy to go with yours. Because XVentanaCondOps instructions are only available

Re: [PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

On 9/5/23 20:33, Tsukasa OI wrote: Internally we have this as: (TARGET_ZICOND || TARGET_XVENTANACONDOPS) I don't really care, so I'm happy to go with yours. Because XVentanaCondOps instructions are only available on 64-bit target (I wanted to prevent misuses because we don't reject

Re: [PATCH] RISC-V: Emit .note.GNU-stack for non-linux target as well

RISC-V qemu default that to false, which mean stack can't execute anything by default, that's match RISC-V linux kernel behaviour, but the problem is risc-v bare metal toolchain may execute code on stack *without* that tag, that does not cause problems before for running tests on qemu user mode,

[Bug c++/111300] New: [14 Regression] g++.dg/modules/xtreme-header-2_b.C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111300 Bug ID: 111300 Summary: [14 Regression] g++.dg/modules/xtreme-header-2_b.C Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3

[COMMITTED] RISC-V: typo: add closing paren to a comment

From: Tsukasa OI gcc/ChangeLog: * config/riscv/zicond.md: Add closing parent to a comment. --- gcc/config/riscv/zicond.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/riscv/zicond.md b/gcc/config/riscv/zicond.md index 1721e1011ea8..c28bee5d5709 100644

Re: [PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

On 2023/09/06 9:17, Jeff Law wrote: > > > On 9/5/23 06:10, Tsukasa OI wrote: >> From: Tsukasa OI >> >> 'XVentanaCondOps' is a vendor extension from Ventana Micro Systems >> containing two instructions for conditional move and will be supported on >> their Veyron V1 CPU. >> >> And most notably

[Bug tree-optimization/111268] [14 Regression] internal compiler error: in to_constant, at poly-int.h:504

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111268 --- Comment #7 from Andrew Pinski --- Interesting: /* We checked above that the vectors are constant-length. */ unsigned vnunits = TYPE_VECTOR_SUBPARTS (vtype).to_constant (); But it is not constant ...

[PATCH v3] RISC-V:Optimize the MASK opt generation

This patch rebases the change of "[PATCH] RISC-V: Optimize the MASK opt generation" and add the new explanation in the options.texi. Please check the detail info on the "https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg302295.html; gcc/ChangeLog: * config/riscv/riscv-opts.h

Re: [PATCH v2] RISC-V: Fix Zicond ICE on large constants

On 2023/09/06 10:22, Jeff Law wrote: > > > On 9/5/23 06:08, Tsukasa OI wrote: >> From: Tsukasa OI >> >> Large constant cons and/or alt will trigger ICEs building GCC target >> libraries (libgomp and libatomic) when the 'Zicond' extension is enabled. >> >> For instance, zicond-ice-2.c (new test

[Bug tree-optimization/111268] [14 Regression] internal compiler error: in to_constant, at poly-int.h:504

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111268 --- Comment #6 from Andrew Pinski --- reducing ...

Re: Re: [PATCH 2/2] [RISC-V] Enalble zcmp for -Os

On 2023-09-05 20:02  Kito Cheng wrote: > >> @@ -5569,7 +5571,9 @@ riscv_avoid_multi_push (const struct riscv_frame_info >> *frame) >>  { >>    if (!TARGET_ZCMP || crtl->calls_eh_return || frame_pointer_needed >>    || cfun->machine->interrupt_handler_p || cfun->machine->varargs_size >>!= 0

[Bug c++/111299] lack of warning on dangling reference to temporary

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111299 --- Comment #2 from Andrew Pinski --- (In reply to Jiang An from comment #1) > > What ends up happening is that in order to bind x.value to the reference > > parameter R&& r, we can't actually do that, so instead we create a > > temporary

Re: [PATCH v2] RISC-V: Fix Zicond ICE on large constants

On 9/5/23 06:08, Tsukasa OI wrote: From: Tsukasa OI Large constant cons and/or alt will trigger ICEs building GCC target libraries (libgomp and libatomic) when the 'Zicond' extension is enabled. For instance, zicond-ice-2.c (new test case in this commit) will cause an ICE when SOME_NUMBER

[Bug c++/111299] lack of warning on dangling reference to temporary

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111299 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #1 from

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

On Tue, Sep 05, 2023 at 09:31:56PM +0800, Xi Ruoyao wrote: > On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote: > > * Support options for LoongArch SIMD extensions: > >   new configure options --with-simd={none,lsx,lasx}; > >   new compiler option -msimd={none,lsx,lasx}; > >   new driver options

Re: [PATCH] RISC-V: Add conditional sqrt autovec pattern

On 9/3/23 22:49, Lehua Ding wrote: This patch adds a combined pattern for combining vfsqrt.v and vcond_mask. gcc/ChangeLog: * config/riscv/autovec-opt.md (*cond_): Add sqrt + vcond_mask combine pattern. * config/riscv/autovec.md (2): Change define_expand to

Re: [PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

On 9/5/23 06:10, Tsukasa OI wrote: From: Tsukasa OI 'XVentanaCondOps' is a vendor extension from Ventana Micro Systems containing two instructions for conditional move and will be supported on their Veyron V1 CPU. And most notably (for historical reasons), 'XVentanaCondOps' and the

Re: [PATCH] xtensa: Optimize boolean evaluation when SImode EQ/NE to zero if TARGET_MINMAX

Hi Suwa-san, On Tue, Sep 5, 2023 at 2:29 AM Takayuki 'January June' Suwa wrote: > > This patch optimizes the boolean evaluation for equality to 0 in SImode > using the MINU (Minimum Value Unsigned) machine instruction available > when TARGET_MINMAX is configured, for example, (x != 0) to MINU(x,

Re: [PATCH] c: Don't pedwarn on _FloatN{,x} or {f,F}N{,x} suffixes for C2X

On Tue, 5 Sep 2023, Jakub Jelinek via Gcc-patches wrote: > Hi! > > Now that _Float{16,32,64,128,32x,64x,128x} and > {f,F}{16,32,64,128,32x,64x,128x} literal suffixes are in C23 standard, > I think it is undesirable to pedwarn about these for -std=c2x, so this > patch uses pedwarn_c11 instead.

Re: [PATCH 13/12 v2] C _BitInt incremental fixes [PR102989]

On Thu, 10 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > On Thu, Aug 10, 2023 at 12:10:07PM +0200, Jakub Jelinek via Gcc-patches wrote: > > Here is an incremental patch which does that: > > Bootstrap/regtest on i686-linux (next to x86_64-linux where it went fine) > revealed I forgot to add {

Re: [PATCH 10/12] C _BitInt support [PR102989]

On Wed, 9 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > Hi! > > This patch adds the C FE support, c-family support, small libcpp change > so that 123wb and 42uwb suffixes are handled plus glimits.h change > to define BITINT_MAXWIDTH macro. > > The previous patches really do nothing without

hey

This is basically if it has any interest..or else ignore... This inverts the digits. So 321 should be 123..not tested We only invert the ten bases, but it can be ok for others. A) 1*10^4 + 2*10^3 + 3*10^2 + 4*10^1 + 5 * 10^0 B) 10^4 + 10^2

Re: [PATCH 17/12] _BitInt a ? ~b : b match.pd fix [PR102989]

On Tue, Sep 5, 2023 at 2:51 PM Jakub Jelinek wrote: > > On Tue, Sep 05, 2023 at 02:27:10PM -0700, Andrew Pinski wrote: > > > I admit it isn't really clear to me what do you want to achieve by the > > > above build_nonstandard_integer_type. Is it because of BOOLEAN_TYPE > > > or perhaps

Re: [PATCH] riscv: Synthesize all 11-bit-rotate constants with rori

Applied to master. Thanks! Philipp. On Tue, 5 Sept 2023 at 23:57, Jeff Law wrote: > > > On 9/5/23 15:15, Christoph Muellner wrote: > > From: Christoph Müllner > > > > Some constants can be built up using LI+RORI instructions. > > The current implementation requires one of the upper 32-bits > >

Re: [PATCH] riscv: Synthesize all 11-bit-rotate constants with rori

On 9/5/23 15:15, Christoph Muellner wrote: From: Christoph Müllner Some constants can be built up using LI+RORI instructions. The current implementation requires one of the upper 32-bits to be a zero bit, which is not neccesary. Let's drop this requirement in order to be able to synthesize

[Bug testsuite/111298] time-profiler-2.c flaky on glibc RISC-V

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111298 --- Comment #2 from Patrick O'Neill --- Yep I'm using qemu-user, thanks for the link.

Re: [PATCH V2] RISC-V: Support Dynamic LMUL Cost model

On 9/5/23 15:39, 钟居哲 wrote: - Why don't we use the normal reverse postorder (or postorder) approach of    computing live ranges?  Is that because we don't really need full global    live ranges? Yes. We don't need global live ranges. - Why can't we use existing code i.e. tree-ssa-live?  I

Re: [PATCH 18/12] Handle BITINT_TYPE in build_{, minus_}one_cst [PR102989]

On Tue, Sep 05, 2023 at 02:42:39PM -0700, Andrew Pinski wrote: > On Tue, Sep 5, 2023 at 12:31 AM Jakub Jelinek via Gcc-patches > > Recent match.pd changes trigger ICE in build_minus_one_cst, apparently > > I forgot to handle BITINT_TYPE in these (while I've handled it in > > build_zero_cst). > > >

[Bug c++/111299] New: lack of warning on dangling reference to temporary

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111299 Bug ID: 111299 Summary: lack of warning on dangling reference to temporary Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3

Re: [PATCH 17/12] _BitInt a ? ~b : b match.pd fix [PR102989]

On Tue, Sep 05, 2023 at 02:27:10PM -0700, Andrew Pinski wrote: > > I admit it isn't really clear to me what do you want to achieve by the > > above build_nonstandard_integer_type. Is it because of BOOLEAN_TYPE > > or perhaps ENUMERAL_TYPE as well? > > Yes I was worried about types where the

Re: [PATCH 18/12] Handle BITINT_TYPE in build_{, minus_}one_cst [PR102989]

On Tue, Sep 5, 2023 at 12:31 AM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > Recent match.pd changes trigger ICE in build_minus_one_cst, apparently > I forgot to handle BITINT_TYPE in these (while I've handled it in > build_zero_cst). > > Will commit as obvious together with the rest of the

[committed] RISC-V: Expose bswapsi for TARGET_64BIT

Various bswapsi tests are failing for rv64. More importantly, we're generating crappy code. Let's take the first test from bswapsi-1.c as an example. typedef unsigned int uint32_t; #define __const_swab32(x) ((uint32_t)(\ (((uint32_t)(x) &

Re: Re: [PATCH V2] RISC-V: Support Dynamic LMUL Cost model

- Why don't we use the normal reverse postorder (or postorder) approach of computing live ranges? Is that because we don't really need full global live ranges? Yes. We don't need global live ranges. - Why can't we use existing code i.e. tree-ssa-live? I suspect I already know the

[Bug testsuite/111298] time-profiler-2.c flaky on glibc RISC-V

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111298 --- Comment #1 from Andrew Pinski --- Are you testing using qemu-user? If so it has always been flaky: https://gcc.gnu.org/pipermail/gcc-patches/2013-November/377091.html

Re: [PATCH 17/12] _BitInt a ? ~b : b match.pd fix [PR102989]

On Tue, Sep 5, 2023 at 12:28 AM Jakub Jelinek via Gcc-patches wrote: > > On Wed, Aug 09, 2023 at 12:19:54PM -0700, Andrew Pinski via Gcc-patches wrote: > > PR tree-optimization/110937 > > PR tree-optimization/100798 > > --- a/gcc/match.pd > > +++ b/gcc/match.pd > > @@ -6460,6 +6460,20

[Bug testsuite/111298] New: time-profiler-2.c flaky on glibc RISC-V

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111298 Bug ID: 111298 Summary: time-profiler-2.c flaky on glibc RISC-V Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug middle-end/98710] missing optimization (x | c) & ~(y | c) -> x & ~(y | c)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98710 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Resolution|---

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 98710, which changed state. Bug 98710 Summary: missing optimization (x | c) & ~(y | c) -> x & ~(y | c) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98710 What|Removed |Added

[Bug tree-optimization/103536] Suboptimal codegen for && and || combination.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103536 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug tree-optimization/107137] (unsigned)-(int)(bool_var) should be optimized to -(unsigned)bool_var

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107137 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|---

[Bug middle-end/98710] missing optimization (x | c) & ~(y | c) -> x & ~(y | c)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98710 --- Comment #5 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:ab286761bf703a43bbd8495cd3fc33a7e88c8440 commit r14-3723-gab286761bf703a43bbd8495cd3fc33a7e88c8440 Author: Andrew Pinski Date:

[Bug tree-optimization/103536] Suboptimal codegen for && and || combination.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103536 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:8e995e84233661a1a246807a66cc84003426b1df commit r14-3722-g8e995e84233661a1a246807a66cc84003426b1df Author: Andrew Pinski Date:

[Bug tree-optimization/107137] (unsigned)-(int)(bool_var) should be optimized to -(unsigned)bool_var

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107137 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:e6bcf83989478348428c732c11e6c0f1719e9214 commit r14-3721-ge6bcf83989478348428c732c11e6c0f1719e9214 Author: Andrew Pinski Date:

[PATCH] riscv: Synthesize all 11-bit-rotate constants with rori

From: Christoph Müllner Some constants can be built up using LI+RORI instructions. The current implementation requires one of the upper 32-bits to be a zero bit, which is not neccesary. Let's drop this requirement in order to be able to synthesize a constant like 0x00ffL. The tests

[Bug tree-optimization/111292] [14 Regression] Missed Dead Code Elimination since r14-2228-g02460c0b8c9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111292 --- Comment #1 from Andrew Pinski --- Looks like there is a missing jump threading ... after the patch.

[Bug tree-optimization/111292] [14 Regression] Missed Dead Code Elimination since r14-2228-g02460c0b8c9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111292 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Summary|Missed Dead

Re: [PATCH V2] RISC-V: Support Dynamic LMUL Cost model

Hi Juzhe, I think the general approach makes sense and it doesn't need to be perfect from the beginning as we can always iterate on it. Before continuing with a more detailed review (hopefully tomorrow) some high-level questions upfront. It would help to document some of these choices so it's

[Bug tree-optimization/111294] [14 Regression] Missed Dead Code Elimination since r14-573-g69f1a8af45d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > In .optimized we have: >[local count: 118111600]: > # _31 = PHI <5(2), 0(3)> > _6 = (int) a.9_28; > _8 = _31 <= 3; > _9 = (int) _8; > if (_6 !=

[Bug tree-optimization/105832] [13/14 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 12.1.0)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105832 Andrew Pinski changed: What|Removed |Added Target Milestone|13.3|14.0 Resolution|---

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 96694, which changed state. Bug 96694 Summary: Failure to optimize min/max pattern using two binary nots to min/max pattern using one binary not https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96694 What

[Bug tree-optimization/96694] Failure to optimize min/max pattern using two binary nots to min/max pattern using one binary not

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96694 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug tree-optimization/105832] [13/14 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 12.1.0)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105832 --- Comment #18 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:b34f373635635fa331d2803d9232b3cfd4fd4fd1 commit r14-3719-gb34f373635635fa331d2803d9232b3cfd4fd4fd1 Author: Andrew Pinski Date:

[Bug tree-optimization/96694] Failure to optimize min/max pattern using two binary nots to min/max pattern using one binary not

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96694 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:244d1321340116b7780e78096356f69662fd0e18 commit r14-3720-g244d1321340116b7780e78096356f69662fd0e18 Author: Andrew Pinski Date:

Re: [PATCH] RISC-V: Emit .note.GNU-stack for non-linux target as well

On Tue, Sep 5, 2023 at 5:14 AM Kito Cheng via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > committed, thanks :) > > On Tue, Sep 5, 2023 at 3:18 PM Jeff Law via Gcc-patches > wrote: > > > > > > > > On 8/31/23 03:05, Kito Cheng wrote: > > > We only emit that on linux target before, that not

Re: [PATCH] c++: Additional warning for name-hiding [PR12341]

On 9/4/23 13:18, priour...@gmail.com wrote: From: benjamin priour Hi, This patch was the first I wrote and had been at that time returned to me because ill-formatted. Getting busy with other things, I forgot about it. I've now fixed the formatting. Succesfully regstrapped on

[Bug ipa/111297] missed optimization: [[unlikely]] attribute has no effect at -O2/-O3/-Ofast due to ICF

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111297 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug ipa/106716] Identical Code Folding (-fipa-icf) confuses between functions with different [[likely]] attributes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106716 Andrew Pinski changed: What|Removed |Added CC||moncef.mechri at gmail dot com ---

Complex numbers in compilers - upcoming GNU Tools Cauldron.

This is going to be an interesting discussion. In the upcoming GNU Tools Cauldron meeting the representation of complex numbers in GCC will be discussed from the following "starting point": "Complex numbers are used to describe many physical phenomenons and are of prime importance in data

Re: [PATCH] c++: Move consteval folding to cp_fold_r

On 9/5/23 15:59, Marek Polacek wrote: On Tue, Sep 05, 2023 at 10:52:04AM -0400, Jason Merrill wrote: On 9/1/23 13:23, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- In the review of P2564:

[Bug c++/111297] New: missed optimization: [[unlikely]] attribute has no effect at -O2/-O3/-Ofast

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111297 Bug ID: 111297 Summary: missed optimization: [[unlikely]] attribute has no effect at -O2/-O3/-Ofast Product: gcc Version: 10.0 Status: UNCONFIRMED Severity:

[Bug c++/111281] unhelpful warning output ('nonnull' argument 'v' compared to NULL)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111281 --- Comment #8 from Frank Heckenbach --- I don't suggest to get rid of the warning. As I said in #3, if it's hard to track, a more inclusive wording seems fine to me. But my main grief about this message is the lack of context, i.e. the really

Re: [PATCH] c++: Move consteval folding to cp_fold_r

On Tue, Sep 05, 2023 at 10:52:04AM -0400, Jason Merrill wrote: > On 9/1/23 13:23, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > > > In the review of P2564: > > > > it

[PATCH 8/8] OpenMP: Fortran "!$omp declare mapper" support

This patch implements "omp declare mapper" functionality for Fortran, following the equivalent support for C and C++. This version of the patch is based on the version posted for the og13 branch: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623357.html and contains some significant

[PATCH 7/8] OpenMP, Fortran: Split out OMP clause checking

This patch breaks out two helper functions from openmp.cc:resolve_omp_clauses, so those parts can be reused in order to improve diagnostics (duplicate clause checking, etc.) after "declare mapper" instantiation in the patch later in this series. This is pretty mechanical -- most previous lines

[PATCH 6/8] OpenMP, Fortran: Per-directive control for gfc_trans_omp_clauses

Some of the processing done by gfc_trans_omp_clauses depends on the directive that that clause is attached to. This patch refactors two booleans and one gfc_exec_op parameter for gfc_trans_omp_clauses into a single parameter of (new) enumerated type 'toc_directive'. The same parameter is also

[PATCH 5/8] OpenMP, Fortran: Pass list number to gfc_free_omp_namelist

This is a cleanup to avoid passing an ever-longer list of boolean arguments to gfc_free_omp_namelist, in support of the Fortran "declare mapper" implementation further along this patch series. This patch isn't intended to cause any behavioural changes. 2023-09-05 Julian Brown gcc/fortran/

[PATCH 4/8] OpenMP: Support OpenMP 5.0 "declare mapper" directives for C

This patch adds support for "declare mapper" directives (and the "mapper" modifier on "map" clauses) for C. It was previously posted for mainline here: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609041.html and for the og13 branch here:

[PATCH 3/8] OpenMP: C++ "declare mapper" support

This patch adds support for OpenMP 5.0 "declare mapper" functionality for C++. This is based on the version of the patch posted for the og13 branch here: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623353.html The following follow up patches/fixes have also been incorporated into this

[PATCH 2/8] OpenMP: lvalue parsing for map/to/from clauses (C)

This patch adds support for parsing general lvalues ("locator list item types") for OpenMP "map", "to" and "from" clauses to the C front-end, similar to the previously-posted patch for C++. Such syntax is permitted for OpenMP 5.0 and above. It was previously posted for mainline here:

[PATCH 0/8] OpenMP: lvalue parsing and "declare mapper" support

This series implements "lvalue" parsing for C and C++ map/to/from clauses, and "declare mapper" support for C, C++ and Fortran. This is the latter part of the series that was previously posted for mainline here: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609031.html and is

[Bug c++/111284] [11/12/13/14 Regression] Some passing-by-value parameters are mishandled since GCC 9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284 --- Comment #5 from Jakub Jelinek --- Ah, /* Associate the bindings with the remapped parms. */ in constexpr.cc remaps those then. So, that loop should take into account also the invisiref parms disagreements.

[Bug c++/111284] [11/12/13/14 Regression] Some passing-by-value parameters are mishandled since GCC 9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284 --- Comment #4 from Jakub Jelinek --- Strange, cxx_bind_parameters_in_call is called on DECL_ARGUMENTS of the function (so the ones modified by the genericization), while the function bodies actually have the parameters remaped (stored in the

[Bug c++/91483] Poor diagnostic on trying to take constexpr reference to non-static object

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91483 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug c++/91483] Poor diagnostic on trying to take constexpr reference to non-static object

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91483 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:b78cedc6b5bc062717a3e0efb10da8e19af1c422 commit r14-3718-gb78cedc6b5bc062717a3e0efb10da8e19af1c422 Author: Marek Polacek Date:

[Bug target/111295] RISC-V vector ICE in vsetvl pass

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111295 --- Comment #1 from Jeremy Bennett --- Further analysis suggests this also causes the following SPEC CPU 2017 benchmarks to fail: 602.gcc_s, 648.exchange2_s, 607.cactuBSSN_s, 621.wrf_s, 627.cam4_s, 628.pop2_s, 638.imagick_s, 649.fotonik3d_s and

[Bug c++/111284] [11/12/13/14 Regression] Some passing-by-value parameters are mishandled since GCC 9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284 --- Comment #3 from Jakub Jelinek --- The PARM_DECL has DECL_ARG_TYPE of reference to S. And the failure is when evaluating the x PARM_DECL as vc_prvalue, else if (tree v = ctx->global->get_value (t)) doesn't find anything.

[Bug middle-end/111296] RISC-V vector: ICE in lra_split_hard_reg_for during reload pass

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111296 --- Comment #1 from Jeremy Bennett --- Created attachment 55844 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55844=edit Testcase (test.cpp)

[Bug middle-end/111296] New: RISC-V vector: ICE in lra_split_hard_reg_for during reload pass

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111296 Bug ID: 111296 Summary: RISC-V vector: ICE in lra_split_hard_reg_for during reload pass Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug c++/111284] [11/12/13/14 Regression] Some passing-by-value parameters are mishandled since GCC 9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment

[Bug tree-optimization/111293] [14 Regression] Missed Dead Code Elimination since r14-3414-g0cfc9c953d0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

[Bug tree-optimization/111293] [14 Regression] Missed Dead Code Elimination since r14-3414-g0cfc9c953d0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293 --- Comment #1 from Andrew Pinski --- The difference is the trunk can figure out the range for j_8: PHI GROUP query for j_8 found : [irange] int [1, 1][8, 8] and adjusted original range from :[irange] int [1, 1][8, 8] to :[irange] int [1, 1][8,

[Bug tree-optimization/111293] [14 Regression] Missed Dead Code Elimination since r14-3414-g0cfc9c953d0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target

Re: [Committed] RISC-V: Add Types to Un-Typed Risc-v Instructions:

On 9/1/2023 11:02 AM, Jeff Law wrote: On 8/31/23 11:32, Edwin Lu wrote: Related Discussion: https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/ This patch updates the riscv instructions to ensure that no insn is left without a type attribute. Added

Re: [Committed] Add Types to Un-Typed Pic Instructions:

On 9/1/2023 6:15 AM, Jeff Law wrote: On 8/31/23 17:01, Edwin Lu wrote: Related Discussion: https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/ This patch updates the pic instructions to ensure that no insn is left without a type attribute. Tested

[Bug middle-end/111295] New: RISC-V vector ICE in vsetvl pass

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111295 Bug ID: 111295 Summary: RISC-V vector ICE in vsetvl pass Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end

[Bug tree-optimization/111294] [14 Regression] Missed Dead Code Elimination since r14-573-g69f1a8af45d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-09-05

[Bug target/111231] armhf: Miscompilation at O2 level (O1 is working)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231 --- Comment #5 from Mathieu Malaterre --- Result from cvise (+manual editing): c++ -Wfatal-errors -Wall -Wextra -Werror -o works -O1 -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee step7.cc -> exit(0) c++ -Wfatal-errors

Re: [PATCH] riscv: xtheadbb: Enable constant synthesis with th.srri

Applied to master. Thanks! Philipp. On Tue, 5 Sept 2023 at 18:10, Jeff Law wrote: > > > On 9/5/23 09:42, Christoph Muellner wrote: > > From: Christoph Müllner > > > > Some constants can be built up using rotate-right instructions. > > The code that enables this can be found in

Re: [PATCH] riscv: xtheadbb: Enable constant synthesis with th.srri

On 9/5/23 09:42, Christoph Muellner wrote: From: Christoph Müllner Some constants can be built up using rotate-right instructions. The code that enables this can be found in riscv_build_integer_1(). However, this functionality is only available for Zbb, which includes the rori instruction.

[Bug tree-optimization/111294] [14 Regression] Missed Dead Code Elimination since r14-573-g69f1a8af45d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294 --- Comment #2 from Andrew Pinski --- The difference is jump threading: old (able to remove foo): ``` Registering killing_def (path_oracle) _4 Registering value_relation (path_oracle) (_4 pe8 _33) (root: bb5) Checking profitability of path

[Bug tree-optimization/111294] [14 Regression] Missed Dead Code Elimination since r14-573-g69f1a8af45d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294 --- Comment #1 from Andrew Pinski --- In .optimized we have: [local count: 118111600]: # _31 = PHI <5(2), 0(3)> _6 = (int) a.9_28; _8 = _31 <= 3; _9 = (int) _8; if (_6 != _9) goto ; [66.00%] else goto ; [34.00%] Except

[Bug tree-optimization/111294] [14 Regression] Missed Dead Code Elimination since r14-573-g69f1a8af45d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target

  1   2   3   >