[COMMITTED] Use range_compatible_p in check_operands_p.

Comments in PR 112788 correctly brought up that the new check_operands_p() routine is directly checking precision rather than calling range_compatible_p(). Most earlier iterations of the original patch had ranges as arguments, and it wasn't primarily a CHECKING_P only call then...   Regardless

[PATCH] gcc: Disallow trampolines when -fhardened

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- It came up that a good hardening strategy is to disable trampolines which may require executable stack. Therefore the following patch adds -Werror=trampolines to -fhardened. gcc/ChangeLog: * common.opt (Wtrampolines):

Re: [PATCH] gcc: Disallow trampolines when -fhardened

On Fri, Dec 1, 2023, 11:36 Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > It came up that a good hardening strategy is to disable trampolines > which may require executable stack. Therefore the following patch > adds -Werror=trampolines to -fha

Re: [PATCH] Fortran: copy-out for possibly missing OPTIONAL CLASS arguments [PR112772]

Hello, Le 30/11/2023 à 22:06, Harald Anlauf a écrit : the attached rather obvious patch fixes the first testcase of pr112772: we unconditionally generated copy-out code for optional class arguments, while the copy-in properly checked the presence of arguments. Regtested on x86_64-pc-linux-gnu.

Re: [PATCH] c++: decltype of (non-captured variable) [PR83167]

On 12/1/23 12:32, Patrick Palka wrote: On Tue, 14 Nov 2023, Jason Merrill wrote: On 11/14/23 11:10, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- For decltype((x)) within a lambda where x is not captured, we dubiously require th

Re: [PATCH] libsupc++: try cxa_thread_atexit_impl at runtime

On Nov 9, 2023, Jonathan Wakely wrote: > On Thu, 9 Nov 2023 at 01:56, Alexandre Oliva wrote: >> g++.dg/tls/thread_local-order2.C fails when the toolchain is built for >> a platform that lacks __cxa_thread_atexit_impl, even if the program is >> built and run using that toolchain on a (later) pl

Re: [PATCH] libsupc++: try cxa_thread_atexit_impl at runtime

On 12/1/23 15:40, Alexandre Oliva wrote: On Nov 9, 2023, Jonathan Wakely wrote: On Thu, 9 Nov 2023 at 01:56, Alexandre Oliva wrote: g++.dg/tls/thread_local-order2.C fails when the toolchain is built for a platform that lacks __cxa_thread_atexit_impl, even if the program is built and run u

Re: [PATCH] gcc: Disallow trampolines when -fhardened

On Fri, Dec 01, 2023 at 11:44:28AM -0800, Andrew Pinski wrote: > On Fri, Dec 1, 2023, 11:36 Marek Polacek wrote: > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > It came up that a good hardening strategy is to disable trampolines > > which may require execut

Re: [PATCH] gcc: Disallow trampolines when -fhardened

On Fri, Dec 01, 2023 at 03:53:14PM -0500, Marek Polacek wrote: > On Fri, Dec 01, 2023 at 11:44:28AM -0800, Andrew Pinski wrote: > > On Fri, Dec 1, 2023, 11:36 Marek Polacek wrote: > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > -- >8 -- > > > It came up that a g

Re: [PATCH] Fortran: copy-out for possibly missing OPTIONAL CLASS arguments [PR112772]

Hi Mikael, On 12/1/23 21:24, Mikael Morin wrote: Hello, Le 30/11/2023 à 22:06, Harald Anlauf a écrit : the attached rather obvious patch fixes the first testcase of pr112772: we unconditionally generated copy-out code for optional class arguments, while the copy-in properly checked the presenc

[PATCH, v3] Fortran: deferred-length character optional dummy arguments [PR93762,PR100651]

Dear all, this patch extends the previous version by adding further code testing the presence of an optional deferred-length character argument also in the function initialization code. This allows to re-enable a commented-out test in v2. Regtested on x86_64-pc-linux-gnu. OK for mainline? Tha

Re: [PATCH] c++: decltype of (non-captured variable) [PR83167]

On Fri, 1 Dec 2023, Jason Merrill wrote: > On 12/1/23 12:32, Patrick Palka wrote: > > On Tue, 14 Nov 2023, Jason Merrill wrote: > > > > > On 11/14/23 11:10, Patrick Palka wrote: > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > > > > trunk? > > > > > > > > -- >8

Re: [PATCH] RISC-V: Fix rawmemchr implementation.

LGTM。 juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-12-01 23:20 To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai CC: rdapp.gcc Subject: [PATCH] RISC-V: Fix rawmemchr implementation. Hi, this fixes a bug in the rawmemchr implementation by incrementing the source addre

Re: [PATCH] RISC-V: Rename and unify stringop strategy handling [NFC].

LGTM juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-12-01 23:21 To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai CC: rdapp.gcc Subject: [PATCH] RISC-V: Rename and unify stringop strategy handling [NFC]. Hi, now split into multiple patches. In preparation for the vec

Re: [PATCH] RISC-V: Add vectorized strlen.

LGTM. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-12-01 23:21 To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai CC: rdapp.gcc Subject: [PATCH] RISC-V: Add vectorized strlen. Hi, this patch implements a vectorized strlen by re-using and slightly adjusting the rawmemc

Re: [PATCH] RISC-V: Add vectorized strcmp.

lgtm juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-12-01 23:23 To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai CC: rdapp.gcc Subject: [PATCH] RISC-V: Add vectorized strcmp. Hi, this patch adds a vectorized strcmp implementation and tests. Similar to strlen, expansi

Re: [PATCH] testsuite: scev: expect fail on ilp32

> Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET) > From: Richard Biener > On Fri, 1 Dec 2023, Hans-Peter Nilsson wrote: > > > > From: Hans-Peter Nilsson > > > Date: Thu, 30 Nov 2023 18:09:10 +0100 > > > > Richard B.: > > > > > In the end we might need to move/duplicate the test to some > > > >

[PATCH v6] c++: implement P2564, consteval needs to propagate up [PR107687]

On Thu, Nov 30, 2023 at 06:34:01PM -0500, Jason Merrill wrote: > On 11/23/23 11:46, Marek Polacek wrote: > > v5 greatly simplifies the code. > > Indeed, it's much cleaner now. > > > I still need a new ff_ flag to signal that we can return immediately > > after seeing an i-e expr. > > That's stil

[PATCH 2/6] c: Turn int-conversion warnings into permerrors

Hi, This patch cause error on building newlib/glibc/musl on RISC-V port: /work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_access.c:8:40: error: passing argument 3 of 'syscall_errno' makes integer from pointer witho

Re: [PATCH v6] c++: implement P2564, consteval needs to propagate up [PR107687]

On 12/1/23 18:37, Marek Polacek wrote: On Thu, Nov 30, 2023 at 06:34:01PM -0500, Jason Merrill wrote: On 11/23/23 11:46, Marek Polacek wrote: v5 greatly simplifies the code. Indeed, it's much cleaner now. I still need a new ff_ flag to signal that we can return immediately after seeing an i

[PATCH v4] RISC-V: Bugfix for legitimize move when get vec mode in zve32f

From: Pan Li If we want to extract 64bit value but ELEN < 64, we use RVV vector mode with EEW = 32 to extract the highpart and lowpart. However, this approach doesn't honor DFmode when movdf pattern when ZVE32f and of course results in ICE when zve32f. This patch would like to reuse the approach

Re: [PATCH v4] RISC-V: Bugfix for legitimize move when get vec mode in zve32f

LGTM juzhe.zh...@rivai.ai From: pan2.li Date: 2023-12-02 08:59 To: gcc-patches CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v4] RISC-V: Bugfix for legitimize move when get vec mode in zve32f From: Pan Li If we want to extract 64bit value but ELEN < 64, we use RVV vec

Re: [PATCH 2/6] c: Turn int-conversion warnings into permerrors

Hi Juzhe, I can confirm the failure on Newlib. I'm not seeing any issues on glibc 2.37. I haven't tried to build musl. Since this patch promotes warnings to errors breakages were probably expected. The fix may require changes to newlib to remove the errors. I've hacked together a series of pat

Re: [PATCH 2/6] c: Turn int-conversion warnings into permerrors

钟居哲 writes: > Hi, This patch cause error on building newlib/glibc/musl on RISC-V port: > > /work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_access.c:8:40: > error: passing argument 3 of 'syscall_errno' makes integ

Re: [PATCH v6 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609]

On Friday, December 1st, 2023 at 9:52 AM, Jason Merrill wrote: > > > On 12/1/23 01:02, waffl3x wrote: > > > I ran into another issue while devising tests for redeclarations of > > xobj member functions as static member functions and vice versa. I am > > pretty sure by the literal wordi

Re: Re: [PATCH 2/6] c: Turn int-conversion warnings into permerrors

No. GLIBC 2.37 also failed: make[4]: Leaving directory '/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/build-newlib/riscv64-unknown-elf/newlib' CC libm/complex/libm_a-casinhl.o make[3]: *** [Makefile:5283: all] Error 2 make[3]: Leaving di

RE: [PATCH v4] RISC-V: Bugfix for legitimize move when get vec mode in zve32f

Committed, thanks Juzhe. Pan From: 钟居哲 Sent: Saturday, December 2, 2023 9:10 AM To: Li, Pan2 ; gcc-patches Cc: Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v4] RISC-V: Bugfix for legitimize move when get vec mode in zve32f LGTM juzhe.zh...@riv

Re: [PATCH 2/6] c: Turn int-conversion warnings into permerrors

That failure is is due to newlib files: /work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../*newlib*/newlib/libm/complex/ccoshl.c: In function 'ccoshl': To build gcc w/ glibc with riscv-gnu-toolchain, run make linux. A temporary fix for newli

Re: [PATCH 2/6] c: Turn int-conversion warnings into permerrors

On 12/1/23 18:13, Sam James wrote: 钟居哲 writes: Hi, This patch cause error on building newlib/glibc/musl on RISC-V port: /work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_access.c:8:40: error: passing argument

[11 PATCH] libiberty, Darwin: Fix a build warning. [PR112823]

From: Iain Sandoe r12-3005-g220c410162ebece4f missed a cast for the set_32 call. Fixed thus. Signed-off-by: Iain Sandoe Signed-off-by: Sam James libiberty/ChangeLog: PR other/112823 * simple-object-mach-o.c (simple_object_mach_o_write_segment): Cast the first argument

Re: [PATCH 2/6] c: Turn int-conversion warnings into permerrors

Jeff Law writes: > On 12/1/23 18:13, Sam James wrote: >> 钟居哲 writes: >> >>> Hi, This patch cause error on building newlib/glibc/musl on RISC-V port: >>> >>> /work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_acces

[PATCH 1/3] MATCH: Fix zero_one_valued_p's convert pattern

While working on PR 111972, I was getting a regression due to zero_one_valued_p matching a signed 1 bit integer when it came to convert. This patch fixes that by checking the outer type too. Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/ChangeLog: * match.pd (zero_

[PATCH 2/3] Remove check of unsigned_char in maybe_undo_optimize_bit_field_compare.

From: Andrew Pinski The check for the type seems unnecessary and gets in the way sometimes. Also with a patch I am working on for match.pd, it causes a failure to happen. Before my patch the IR was: _1 = BIT_FIELD_REF ; _2 = _1 & 1; _3 = _2 != 0; _4 = (int) _3; __analyzer_eval (_4); Wh

[PATCH 0/3] Fix PR 111972

This patch set fixes PR 111972 and the fallout from it. The first patch is a fix to zero_one_valued_p's convert pattern which I hit while running the testsuite with the last patch. The second patch is a fix for -fanalyzer which I had implemented with a different version of the 3rd patch while I w

[PATCH 3/3] MATCH: (convert)(zero_one !=/== 0/1) for outer type and zero_one type are the same

When I moved two_value to match.pd, I removed the check for the {0,+-1} as I had placed it after the {0,+-1} case for cond in match.pd. In the case of {0,+-1} and non boolean, before we would optmize those case to just `(convert)a` but after we would get `(convert)(a != 0)` which was not handled an

Re: [11 PATCH] libiberty, Darwin: Fix a build warning. [PR112823]

HI Sam, I think this qualifies as obvious (it’s on my list, but I did not get to it yet, so go ahead). Iain > On 2 Dec 2023, at 05:30, Sam James wrote: > > From: Iain Sandoe > > r12-3005-g220c410162ebece4f missed a cast for the set_32 call. > Fixed thus. > > Signed-off-by: Iain Sandoe > Si

Re: [11 PATCH] libiberty, Darwin: Fix a build warning. [PR112823]

Iain Sandoe writes: > HI Sam, Hi Iain, > > I think this qualifies as obvious (it’s on my list, but I did not get to it > yet, > so go ahead). Thanks. I can't push it myself - could you do that for me? thanks again, sam > > Iain > >> On 2 Dec 2023, at 05:30, Sam James wrote: >> >> From:

<    1   2