[PATCH] fortran: Remove reference count update [PR108957]

Hello, Harald reminded me recently that there was a working patch attached to the PR. I added a documentation comment with the hope that it may help avoid making the same mistake in the future. Regression tested on x86_64-pc-linux-gnu. OK for master? -- >8 -- Remove one reference count increment

Re: Question on -fwrapv and -fwrapv-pointer

On Thu, 2023-09-14 at 21:41 +, Qing Zhao wrote: > > > CLANG already provided -fsanitize=unsigned-integer-overflow. GCC > > > might need to do the same. > > > > NO. There is no such thing as unsigned integer overflow. That option > > is badly designed and the GCC community has rejected a few ti

[PATCH] aarch64: Fix loose ldpstp check [PR111411]

aarch64_operands_ok_for_ldpstp contained the code: /* One of the memory accesses must be a mempair operand. If it is not the first one, they need to be swapped by the peephole. */ if (!aarch64_mem_pair_operand (mem_1, GET_MODE (mem_1)) && !aarch64_mem_pair_operand (mem_2, GET

[PATCH] test: Remove XPASS for RISCV

Like ARM SVE, this test cause FAILs of XPASS: XPASS: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 72) XPASS: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 77) XPASS: gcc.dg/Wstringop-overflow-47.c pr97027 note (test for warnings, line 68) on RISC-V gcc/testsui

Re: [PATCH] RISC-V: Refactor expand_reduction and cleanup enum reduction_type

LGTM On Fri, Sep 15, 2023 at 1:06 PM Lehua Ding wrote: > This patch refactors expand_reduction, remove the reduction_type argument > and add insn_flags argument to determine the passing of the operands. > ops has also been modified to restrict it to only two cases and to remove > operand that ar

Re: [PATCH] [RISC-V] fix PR 111259 invalid zcmp mov predicate.

I guess another solution is using reg_or_subregno instead of REGNO, but that should not catch more cases, and just more run-time check, so this version is LGTM.

[PATCH] test: Block slp-16.c check for target support vect_strided6

This testcase FAIL in RISC-V because RISC-V support vect_load_lanes with 6. FAIL: gcc.dg/vect/slp-16.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorizing stmts using SLP" 2 FAIL: gcc.dg/vect/slp-16.c scan-tree-dump-times vect "vectorizing stmts using SLP" 2 Since it use vlseg6 (vect

Re: [PATCH] Fortran: improve bounds-checking for array sections [PR30802]

Hi Harald, The statement, in array_bound_check_elemental is redundant since the call is determined by a more restrictive condition. + if (!(gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)) +return; Apart from that, it looks good to me. OK for mainline. Thanks for the patch. Paul On Thu, 14 Sep

Re: [PATCH] fortran: Remove reference count update [PR108957]

Hi Mikael, The comment is very welcome! Looks good to me. OK for mainline. Thanks for the patch. Paul On Fri, 15 Sept 2023 at 08:19, Mikael Morin via Fortran wrote: > > Hello, > > Harald reminded me recently that there was a working patch attached to the PR. > I added a documentation comment w

[PATCH] test: Isolate slp-1.c check of target supports vect_strided5

This test failed in RISC-V: FAIL: gcc.dg/vect/slp-1.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorizing stmts using SLP" 4 FAIL: gcc.dg/vect/slp-1.c scan-tree-dump-times vect "vectorizing stmts using SLP" 4 Because this loop: /* SLP with unrolling by 8. */ for (i = 0; i < N; i

[WIP] Re-introduce 'TREE_USED' in tree streaming

Hi! Now, that was another quirky debug session: in 'gcc/omp-low.cc:create_omp_child_function' we clearly do set 'TREE_USED (t) = 1;' for '.omp_data_i', which ends up as formal parameter for outlined '[...]._omp_fn.[...]' functions, pointing to the "OMP blob". Yet, in offloading compilation, I only

[committed] libstdc++: Add operator bool to result types (P2497R0)

Tested x86_64-linux. Pushed to trunk. This was supposed to be in C++23, but I messed up the polls at the last meeting for C++23 ballot resolution. I've heard suggestions that we should just backport it to C++23 as a nice quality of life improvement, but I've also heard objections to any such featu

[committed] libstdc++: Remove non-void static assertions in variant's std::get [PR111172]

Tested x86_64-linux. Pushed to trunk. This would be safe to backport and slightly improve compile times. -- >8 -- A void template argument would cause a substitution failure when trying to form a reference for the return type, so the function body would never be instantiated. libstdc++-v3/Chang

[committed] libstdc++: Fix constraints for std::variant default constructor

Tested x86_64-linux. Pushed to trunk. Thanks to Nina Ranns for noticing this bug. Removing the base class isn't an ABI change. It's an empty base class with a type that's unique to the std::variant that derives from it, so doesn't change whether two std::variant subobjects can be overlapping. --

Re: [PATCH] test: Remove XPASS for RISCV

On Fri, 15 Sep 2023, Juzhe-Zhong wrote: > Like ARM SVE, this test cause FAILs of XPASS: > XPASS: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 72) > XPASS: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 77) > XPASS: gcc.dg/Wstringop-overflow-47.c pr97027 note (te

Re: [PATCH] test: Block slp-16.c check for target support vect_strided6

On Fri, 15 Sep 2023, Juzhe-Zhong wrote: > This testcase FAIL in RISC-V because RISC-V support vect_load_lanes with 6. > FAIL: gcc.dg/vect/slp-16.c -flto -ffat-lto-objects scan-tree-dump-times vect > "vectorizing stmts using SLP" 2 > FAIL: gcc.dg/vect/slp-16.c scan-tree-dump-times vect "vectorizi

Re: [PATCH] test: Isolate slp-1.c check of target supports vect_strided5

On Fri, 15 Sep 2023, Juzhe-Zhong wrote: > This test failed in RISC-V: > FAIL: gcc.dg/vect/slp-1.c -flto -ffat-lto-objects scan-tree-dump-times vect > "vectorizing stmts using SLP" 4 > FAIL: gcc.dg/vect/slp-1.c scan-tree-dump-times vect "vectorizing stmts using > SLP" 4 > > Because this loop: >

Re: [Patch][v5] OpenMP: Move omp requires checks to libgomp

Hi! On 2022-07-01T15:06:05+0200, Tobias Burnus wrote: > OpenMP: Move omp requires checks to libgomp This became commit r13-1458-g683f11843974f0bdf42f79cdcbb0c2b43c7b81b0 "OpenMP: Move omp requires checks to libgomp". As of this, when I need to debug an offloading-compilation ICE, for example,

[PATCH] test: Block vect_strided5 for slp-34-big-array.c SLP check

If failed on RISC-V since it use vect_store_lanes with array 5. gcc/testsuite/ChangeLog: * gcc.dg/vect/slp-34-big-array.c: Block SLP check for vect_strided5. --- gcc/testsuite/gcc.dg/vect/slp-34-big-array.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/testsuit

[PATCH] test: Block SLP check of slp-34.c for vect_strided5

Since RISC-V use vsseg5 which is the vect_store_lanes with stride 5 if failed on RISC-V. gcc/testsuite/ChangeLog: * gcc.dg/vect/slp-34.c: Block check for vect_strided5. --- gcc/testsuite/gcc.dg/vect/slp-34.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/testsui

[PATCH] test: Block SLP check of slp-35.c for vect_strided5

gcc/testsuite/ChangeLog: * gcc.dg/vect/slp-35.c: Block SLP check for vect_strided5 targets. --- gcc/testsuite/gcc.dg/vect/slp-35.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/testsuite/gcc.dg/vect/slp-35.c b/gcc/testsuite/gcc.dg/vect/slp-35.c index 5e9f6739e1

Re: [PATCH] test: Block vect_strided5 for slp-34-big-array.c SLP check

On Fri, 15 Sep 2023, Juzhe-Zhong wrote: > If failed on RISC-V since it use vect_store_lanes with array 5. OK. > gcc/testsuite/ChangeLog: > > * gcc.dg/vect/slp-34-big-array.c: Block SLP check for vect_strided5. > > --- > gcc/testsuite/gcc.dg/vect/slp-34-big-array.c | 2 +- > 1 file chang

Re: [PATCH] test: Block SLP check of slp-35.c for vect_strided5

On Fri, 15 Sep 2023, Juzhe-Zhong wrote: > gcc/testsuite/ChangeLog: OK. > * gcc.dg/vect/slp-35.c: Block SLP check for vect_strided5 targets. > > --- > gcc/testsuite/gcc.dg/vect/slp-35.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/testsuite/gcc.dg/vect/slp

Re: [PATCH] test: Block SLP check of slp-34.c for vect_strided5

On Fri, 15 Sep 2023, Juzhe-Zhong wrote: > Since RISC-V use vsseg5 which is the vect_store_lanes with stride 5 > if failed on RISC-V. OK. > gcc/testsuite/ChangeLog: > > * gcc.dg/vect/slp-34.c: Block check for vect_strided5. > > --- > gcc/testsuite/gcc.dg/vect/slp-34.c | 2 +- > 1 file ch

Re: [WIP] Re-introduce 'TREE_USED' in tree streaming

On Fri, Sep 15, 2023 at 11:20 AM Thomas Schwinge wrote: > > Hi! > > Now, that was another quirky debug session: in > 'gcc/omp-low.cc:create_omp_child_function' we clearly do set > 'TREE_USED (t) = 1;' for '.omp_data_i', which ends up as formal parameter > for outlined '[...]._omp_fn.[...]' functio

Re: [PATCH] RISC-V: Refactor expand_reduction and cleanup enum reduction_type

Committed, thanks Kito. On 2023/9/15 16:46, Kito Cheng wrote: LGTM On Fri, Sep 15, 2023 at 1:06 PM Lehua Ding > wrote: This patch refactors expand_reduction, remove the reduction_type argument and add insn_flags argument to determine the passing of the

RE: [PATCH] test: Isolate slp-1.c check of target supports vect_strided5

Committed, thanks Richard. Pan -Original Message- From: Gcc-patches On Behalf Of Richard Biener via Gcc-patches Sent: Friday, September 15, 2023 5:38 PM To: Juzhe-Zhong Cc: gcc-patches@gcc.gnu.org; jeffreya...@gmail.com; richard.sandif...@arm.com Subject: Re: [PATCH] test: Isolate slp-

RE: [PATCH] test: Block slp-16.c check for target support vect_strided6

Committed, thanks Richard. Pan -Original Message- From: Gcc-patches On Behalf Of Richard Biener via Gcc-patches Sent: Friday, September 15, 2023 5:38 PM To: Juzhe-Zhong Cc: gcc-patches@gcc.gnu.org; jeffreya...@gmail.com; richard.sandif...@arm.com Subject: Re: [PATCH] test: Block slp-16

RE: [PATCH] test: Block vect_strided5 for slp-34-big-array.c SLP check

Committed, thanks Richard. Pan -Original Message- From: Gcc-patches On Behalf Of Richard Biener via Gcc-patches Sent: Friday, September 15, 2023 6:07 PM To: Juzhe-Zhong Cc: gcc-patches@gcc.gnu.org; jeffreya...@gmail.com Subject: Re: [PATCH] test: Block vect_strided5 for slp-34-big-arra

RE: [PATCH] test: Block SLP check of slp-34.c for vect_strided5

Committed, thanks Richard. Pan -Original Message- From: Gcc-patches On Behalf Of Richard Biener via Gcc-patches Sent: Friday, September 15, 2023 6:07 PM To: Juzhe-Zhong Cc: gcc-patches@gcc.gnu.org; jeffreya...@gmail.com Subject: Re: [PATCH] test: Block SLP check of slp-34.c for vect_st

RE: [PATCH] test: Block SLP check of slp-35.c for vect_strided5

Committed, thanks Richard. Pan -Original Message- From: Gcc-patches On Behalf Of Richard Biener via Gcc-patches Sent: Friday, September 15, 2023 6:07 PM To: Juzhe-Zhong Cc: gcc-patches@gcc.gnu.org; jeffreya...@gmail.com Subject: Re: [PATCH] test: Block SLP check of slp-35.c for vect_st

[PATCH] RISC-V: Fix using wrong mode to get reduction insn vlmax

This patch fix using wrong mode when emit vlmax reduction insn. We should use src operand instead dest operand (which always LMUL=m1) to get the vlmax length. This patch alse remove dest_mode and mask_mode from insn_expander constructor, which can be geted by insn_flags. gcc/ChangeLog: *

[PATCH][RFC] middle-end/106811 - document GENERIC/GIMPLE undefined behavior

The following attempts to provide a set of conditions GENERIC/GIMPLE considers invoking undefined behavior, leaning on the C standards Annex J, as to provide portability guidance to language frontend developers. I've both tried to remember cases we exploit undefined behavior and went over C2x Anne

Re: Question on -fwrapv and -fwrapv-pointer

Qing Zhao writes: > Even though unsigned integer overflow is well defined, it might be > unintentional, shall we warn user about this? This would be better addressed by providing operators or functions that do overflow checking in the language, so that they can be explicitly used where overflow

Re: [PATCH] RISC-V: Fix using wrong mode to get reduction insn vlmax

Committed, thanks Juzhe. On 2023/9/15 19:18, juzhe.zhong wrote: lgtm Replied Message FromLehua Ding Date09/15/2023 19:13 To gcc-patches@gcc.gnu.org Cc juzhe.zh...@rivai.ai , kito.

Re: [WIP] Re-introduce 'TREE_USED' in tree streaming

Hi! On 2023-09-15T12:11:44+0200, Richard Biener via Gcc-patches wrote: > On Fri, Sep 15, 2023 at 11:20 AM Thomas Schwinge > wrote: >> Now, that was another quirky debug session: in >> 'gcc/omp-low.cc:create_omp_child_function' we clearly do set >> 'TREE_USED (t) = 1;' for '.omp_data_i', which e

Re: [WIP] Re-introduce 'TREE_USED' in tree streaming

On Fri, Sep 15, 2023 at 3:01 PM Thomas Schwinge wrote: > > Hi! > > On 2023-09-15T12:11:44+0200, Richard Biener via Gcc-patches > wrote: > > On Fri, Sep 15, 2023 at 11:20 AM Thomas Schwinge > > wrote: > >> Now, that was another quirky debug session: in > >> 'gcc/omp-low.cc:create_omp_child_funct

Re: [PATCH] Checking undefined_p before using the vr

On 9/14/23 22:07, Jiufu Guo wrote: undefined is a perfectly acceptable range.  It can be used to represent either values which has not been initialized, or more frequently it identifies values that cannot occur due to conflicting/unreachable code.  VARYING means it can be any range, UNDEFINED

Re: [WIP] Re-introduce 'TREE_USED' in tree streaming

On Fri, Sep 15, 2023 at 3:05 PM Richard Biener wrote: > > On Fri, Sep 15, 2023 at 3:01 PM Thomas Schwinge > wrote: > > > > Hi! > > > > On 2023-09-15T12:11:44+0200, Richard Biener via Gcc-patches > > wrote: > > > On Fri, Sep 15, 2023 at 11:20 AM Thomas Schwinge > > > wrote: > > >> Now, that wa

[PATCH v1] RISC-V: Support FP SGNJX autovec for VLS mode

From: Pan Li This patch would like to allow the VLS mode autovec for the floating-point binary operation SGNJX. Give sample code as below: void test (float * restrict out, float * restrict in1, float * restrict in2) { for (int i = 0; i < 128; i++) out[i] = in1[i] * copysignf (1.0, in2[i])

Re: Machine Mode ICE in RISC-V when LTO

Hi Thomas, Jakub, is there anything we can do to assist from the riscv side in order to help with this? I haven't really been involved with it but was wondering what's missing. If I understand correctly Thomas has a major cleanup operation in plan but might not get to it soon. The fix he propos

Re: [PATCH] tree optimization/111407--SSA corruption due to widening_mul opt

thanks. Committed as https://gcc.gnu.org/pipermail/gcc-cvs/2023-September/389614.html Qing > On Sep 15, 2023, at 2:12 AM, Richard Biener > wrote: > > On Thu, Sep 14, 2023 at 3:25 PM Qing Zhao via Gcc-patches > wrote: >> >> on conflict across an abnormal edge >> >> This is a bug in tree-ssa-

[COMMITTED 1/2] Fix indentation in range_of_phi.

Somewhere along the way a large sequence of code in range_of_phi() ended up with the same indentation of the preceeding loop.. this simply fixes it. committed as obvious. Andrew From e35c3b5335879afb616c6ead0f41bf6c275ee941 Mon Sep 17 00:00:00 2001 From: Andrew MacLeod Date: Wed, 13 Sep 2023 0

[COMMITTED 2/2] Always do PHI analysis before loop analysis.

The original invocation of phi_analysis was only invoked if there was no loop information available.  I have found situations where phi analysis enhances existing loop information, and as such this patch moves the phi analysis block to before loop analysis is invoked (in case a query is made fr

[COMMITTED] ada: Crash on creation of extra formals on type extension

From: Javier Miranda Revert previous patch and fix the pending issue. gcc/ada/ * accessibility.ads (Needs_Result_Accessibility_Extra_Formal): Removed. * accessibility.adb (Needs_Result_Accessibility_Level_Param): Removed. (Needs_Result_Accessibility_Extra

[COMMITTED] ada: Clean up scope depth and related code (tech debt)

From: Bob Duff The main point of this patch is to remove the special case for Atree.F_Scope_Depth_Value in the Assert that Field_Present in Get_Field_Value. Pulling on that thread leads to lots of related cleanup. gcc/ada/ChangeLog: * atree.adb (Node_Kind_Table): Specify parameter expli

[COMMITTED] ada: Fix internal error on aggregate nested in container aggregate

From: Eric Botcazou This handles the case where a component association is present. gcc/ada/ * exp_aggr.adb (Convert_To_Assignments): In the case of a component association, call Is_Container_Aggregate on the parent's parent. (Expand_Array_Aggregate): Likewise.

[COMMITTED] ada: Do not perform local-exception-to-goto optimization on barrier functions

From: Patrick Bernardi The local-exception-to-goto optimization is no longer applied to entry barrier functions as entry barriers cannot contain exception handlers and this optimization interferes with another optimization that occurs for simple barrier functions. In particular, the simple barri

[COMMITTED] ada: Fix internal error on expression function with Refined_Post aspect

From: Eric Botcazou This occurs when the expression function calls a protected function and the -gnata switch is specified, because the compiler wrongly freezes the called function when analyzing the expression function, a fallout of the wrapping scheme used for the Post and Refined_Post aspects.

[COMMITTED] ada: Generate runtime restrictions list when the standard library is suppressed

From: Patrick Bernardi With the introduction of Jorvik support into the light-tasking runtime comes the requirement to detect voliations of runtime restrictions (for example Max_Entry_Queue_Length) where previously they could be hard coded in the runtime. This means we now need the binder to popu

[COMMITTED] ada: Remove GNAT Pro details regarding mold

From: Kévin Le Gouguec gcc/ada/ * doc/gnat_ugn/building_executable_programs_with_gnat.rst: Remove extended discussion regarding mold run-time dependencies; packaging changes in GNAT Pro have made them obsolete. Tested on x86_64-pc-linux-gnu, committed on master. --- ..

[COMMITTED] ada: Fix wrong optimization of extended return for discriminated record type

From: Eric Botcazou This happens when the discriminants of the record type have default values. gcc/ada/ChangeLog: * inline.adb (Expand_Inlined_Call): In the case of a function call that returns an unconstrained type and initializes an object, set the No_Initialization f

[COMMITTED] ada: Fix internal error on misaligned component with variable nominal size

From: Eric Botcazou The back-end cannot handle this kind of components even when they are small. gcc/ada/ * exp_util.adb (Component_May_Be_Bit_Aligned): Do not return false for a small component of a record type with a variant part. Tested on x86_64-pc-linux-gnu, committed on m

[COMMITTED] ada: Fix minor glitch in finish_record_type

From: Eric Botcazou The size needs to be rounded up to the storage unit in all cases. gcc/ada/ * gcc-interface/utils.cc (finish_record_type): Round the size in the padding case as well. Tested on x86_64-pc-linux-gnu, committed on master. --- gcc/ada/gcc-interface/utils.cc | 2

[COMMITTED] ada: Explicitly analyze and expand null array aggregates

From: Piotr Trojanek Null array aggregates have present but empty lists of expressions and component associations. This confuses the previous code for ordinary array aggregates, which assumes that if a list of either expressions or component associations is present, then it is non-empty. This pa

[PATCH] [RFC] New early __builtin_unreachable processing.

Ive been looking at __builtin_unreachable () regressions.  The fundamental problem seems to be  a lack of consistent expectation for when we remove it earlier than the final pass of VRP.    After looking through them, I think this provides a sensible approach. Ranger is pretty good at providin

Re: [PATCH] ira: Consider save/restore costs of callee-save registers [PR110071]

On 9/14/23 06:45, Surya Kumari Jangala wrote: ira: Consider save/restore costs of callee-save registers [PR110071] In improve_allocation() routine, IRA checks for each allocno if spilling any conflicting allocnos can improve the allocation of this allocno. This routine computes the cost improv

Re: [PATCH] MATCH: Improve zero_one_valued_p for cases without range information

On Thu, Sep 14, 2023 at 11:28 PM Richard Biener via Gcc-patches wrote: > > On Fri, Sep 15, 2023 at 3:09 AM Andrew Pinski via Gcc-patches > wrote: > > > > I noticed we sometimes lose range information in forwprop due to a few > > match and simplify patterns optimizing away casts. So the easier way

[PATCH] gcc: Introduce -fhardened

Bootstrapped/regtested on x86_64-pc-linux-gnu, powerpc64le-unknown-linux-gnu, and aarch64-unknown-linux-gnu; ok for trunk? -- >8 -- In I proposed -fhardened, a new umbrella option that enables a reasonable set of hardening flags.

Re: RFC: Introduce -fhardened to enable security-related flags

On Wed, Aug 30, 2023 at 10:46:14AM +0200, Martin Uecker wrote: > > Improving the security of software has been a major trend in the recent > > years. Fortunately, GCC offers a wide variety of flags that enable extra > > hardening. These flags aren't enabled by default, though. And since > > ther

Re: RFC: Introduce -fhardened to enable security-related flags

On Wed, Aug 30, 2023 at 05:06:57PM +0800, Xi Ruoyao via Gcc-patches wrote: > On Tue, 2023-08-29 at 15:42 -0400, Marek Polacek via Gcc-patches wrote: > > + if (UNLIKELY (flag_hardened) > > + && (opt->code == OPT_D || opt->code == OPT_U)) > > +   { > > + if (!f

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 15, 2023, at 3:43 AM, Xi Ruoyao wrote: > > On Thu, 2023-09-14 at 21:41 +, Qing Zhao wrote: CLANG already provided -fsanitize=unsigned-integer-overflow. GCC might need to do the same. >>> >>> NO. There is no such thing as unsigned integer overflow. That option >>> is badl

Re: RFC: Introduce -fhardened to enable security-related flags

On Wed, Aug 30, 2023 at 12:50:40PM +0200, Jakub Jelinek wrote: > On Tue, Aug 29, 2023 at 03:42:27PM -0400, Marek Polacek via Gcc-patches wrote: > > + if (UNLIKELY (flag_hardened) > > + && (opt->code == OPT_D || opt->code == OPT_U)) > > + { > > + if (!fortify_seen_p) > > +

Re: Question on -fwrapv and -fwrapv-pointer

On Fri, Sep 15, 2023 at 8:12 AM Qing Zhao wrote: > > > > > On Sep 15, 2023, at 3:43 AM, Xi Ruoyao wrote: > > > > On Thu, 2023-09-14 at 21:41 +, Qing Zhao wrote: > CLANG already provided -fsanitize=unsigned-integer-overflow. GCC > might need to do the same. > >>> > >>> NO. There is n

Re: RFC: Introduce -fhardened to enable security-related flags

On Wed, Aug 30, 2023 at 03:08:46PM +0200, Richard Biener wrote: > On Wed, Aug 30, 2023 at 12:51 PM Jakub Jelinek via Gcc-patches > wrote: > > > > On Tue, Aug 29, 2023 at 03:42:27PM -0400, Marek Polacek via Gcc-patches > > wrote: > > > + if (UNLIKELY (flag_hardened) > > > + && (opt

Re: RFC: Introduce -fhardened to enable security-related flags

On Mon, Sep 04, 2023 at 11:40:34PM +0100, Richard Sandiford wrote: > Qing Zhao via Gcc-patches writes: > >> On Aug 29, 2023, at 3:42 PM, Marek Polacek via Gcc-patches > >> wrote: > >> > >> Improving the security of software has been a major trend in the recent > >> years. Fortunately, GCC offe

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 15, 2023, at 8:41 AM, Arsen Arsenović wrote: > > > Qing Zhao writes: > >> Even though unsigned integer overflow is well defined, it might be >> unintentional, shall we warn user about this? > > This would be better addressed by providing operators or functions that > do overflow ch

Re: [PATCH V4] RISC-V: Expand VLS mode to scalar mode move[PR111391]

On 9/14/23 16:26, 钟居哲 wrote: I don't think it can fix the case when it is -march=rv64gc_zve32x juzhe.zh...@rivai.ai *From:* Kito Cheng *Date:* 2023-09-15 00:17 *To:* Juzhe-Zhong

Re: Question on -fwrapv and -fwrapv-pointer

> Am 15.09.2023 um 17:25 schrieb Qing Zhao : > >  > >> On Sep 15, 2023, at 8:41 AM, Arsen Arsenović wrote: >> >> >> Qing Zhao writes: >> >>> Even though unsigned integer overflow is well defined, it might be >>> unintentional, shall we warn user about this? >> >> This would be better ad

Re: Re: [PATCH V4] RISC-V: Expand VLS mode to scalar mode move[PR111391]

You mean this patch is ok? juzhe.zh...@rivai.ai From: Jeff Law Date: 2023-09-15 23:27 To: 钟居哲; kito.cheng CC: gcc-patches; kito.cheng; rdapp.gcc Subject: Re: [PATCH V4] RISC-V: Expand VLS mode to scalar mode move[PR111391] On 9/14/23 16:26, 钟居哲 wrote: > I don't think it can fix the case wh

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 15, 2023, at 11:29 AM, Richard Biener > wrote: > > > >> Am 15.09.2023 um 17:25 schrieb Qing Zhao : >> >>  >> >>> On Sep 15, 2023, at 8:41 AM, Arsen Arsenović wrote: >>> >>> >>> Qing Zhao writes: >>> Even though unsigned integer overflow is well defined, it might be

Re: RFC: Introduce -fhardened to enable security-related flags

On Fri, Sep 01, 2023 at 10:09:28PM +, Qing Zhao via Gcc-patches wrote: > > > > On Aug 29, 2023, at 3:42 PM, Marek Polacek via Gcc-patches > > wrote: > > > > Improving the security of software has been a major trend in the recent > > years. Fortunately, GCC offers a wide variety of flags t

Re: [PATCH V4] RISC-V: Expand VLS mode to scalar mode move[PR111391]

> You mean this patch is ok? I thought about it a bit more. From my point of view the patch is OK for now in order to get the bug out of the way. In the longer term I would really prefer a more "regular" solution (i.e. via hard_regno_mode_ok) and related. I can take care of that once I have a b

[PATCH] c++: overeager type completion in convert_to_void [PR111419]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here convert_to_void always completes the type of an INDIRECT_REF or VAR_DECL expression, but according to [expr.context] an lvalue-to-rvalue conversion is applied to a discarded-value expression only if "the

[PATCH] c++: visibility wrt template and ptrmem targs [PR70413]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- When constraining the visibility of an instantiation, we weren't properly considering the visibility of PTRMEM_CST and TEMPLATE_DECL template arguments. PR c++/70413 gcc/cp/ChangeLog: * dec

Re: [PATCH] [RISC-V] fix PR 111259 invalid zcmp mov predicate.

On 9/15/23 01:49, Kito Cheng via Gcc-patches wrote: I guess another solution is using reg_or_subregno instead of REGNO, but that should not catch more cases, and just more run-time check, so this version is LGTM. I tested an equivalent patch (without the comment changes). This patch resolves th

Re: [PATCH 2/2 v2] Ada: Finalization of constrained subtypes of unconstrained synchronized private extensions

Richard, As a follow-on to my earlier message, additional testing has uncovered an issue with your patch. When run against a compiler built with assertions enabled, the test of "Present (Corresponding_Record_Type (Parent_Utyp))" can fail. An additional guard is needed prior to that test, as follo

Re: Question on -fwrapv and -fwrapv-pointer

On Fri, 2023-09-15 at 15:37 +, Qing Zhao wrote: > > > > On Sep 15, 2023, at 11:29 AM, Richard Biener > > wrote: > > > > > > > > > Am 15.09.2023 um 17:25 schrieb Qing Zhao : > > > > > >  > > > > > > > On Sep 15, 2023, at 8:41 AM, Arsen Arsenović > > > > wrote: > > > > > > > > > > > >

Re: Question on -fwrapv and -fwrapv-pointer

> Am 15.09.2023 um 17:37 schrieb Qing Zhao : > >  > >>> On Sep 15, 2023, at 11:29 AM, Richard Biener >>> wrote: >>> >>> >>> Am 15.09.2023 um 17:25 schrieb Qing Zhao : >>> >>>  >>> On Sep 15, 2023, at 8:41 AM, Arsen Arsenović wrote: Qing Zhao writes:

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 15, 2023, at 1:26 PM, Richard Biener > wrote: > > > >> Am 15.09.2023 um 17:37 schrieb Qing Zhao : >> >>  >> On Sep 15, 2023, at 11:29 AM, Richard Biener wrote: > Am 15.09.2023 um 17:25 schrieb Qing Zhao :  > On Sep 15, 2023,

[pushed] analyzer: handle volatile ops

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r14-4040-g6319b5b2d46690. gcc/analyzer/ChangeLog: * region-model.cc (region_model::get_gassign_result): Handle volatile ops by using a conjured_svalue. gcc/testsuite/ChangeLog: * c-c++-common

[pushed] analyzer: introduce pending_location

No functional change intended. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r14-4041-g759a1a52ea615d. gcc/analyzer/ChangeLog: * analyzer.h (struct pending_location): New forward decl. * diagnostic-manager.cc (saved_diagnostic::saved_diagnostic)

[pushed] analyzer: support diagnostics that don't have a stmt

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r14-4042-gb09193fb0686b7. gcc/analyzer/ChangeLog: * analyzer.cc (get_stmt_location): Handle null stmt. * diagnostic-manager.cc (saved_diagnostic::saved_diagnostic): Copy m_loc from ploc.

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 15, 2023, at 12:53 PM, Xi Ruoyao wrote: > > On Fri, 2023-09-15 at 15:37 +, Qing Zhao wrote: >> >> >>> On Sep 15, 2023, at 11:29 AM, Richard Biener >>> wrote: >>> >>> >>> Am 15.09.2023 um 17:25 schrieb Qing Zhao :  > On Sep 15, 2023, at 8:41 AM, Arse

[PATCH] c++: constness of decltype of NTTP object [PR98820]

bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13? -- >8 -- This corrects decltype of a (class) NTTP object as per [dcl.type.decltype]/1.2 and [temp.param]/6 in the type-dependent case. In the non-dependent case (nontype-class8.C) we resolve the decltype ahead of t

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

On 9/13/23 20:02, Marek Polacek wrote: On Wed, Sep 13, 2023 at 05:57:47PM -0400, Jason Merrill wrote: On 9/13/23 16:56, Marek Polacek wrote: On Tue, Sep 12, 2023 at 05:26:25PM -0400, Jason Merrill wrote: On 9/8/23 14:24, Marek Polacek wrote: + switch (TREE_CODE (stmt)) +{ +/* Unfortu

Re: Question on -fwrapv and -fwrapv-pointer

On Fri, Sep 15, 2023 at 08:18:28AM -0700, Andrew Pinski wrote: > On Fri, Sep 15, 2023 at 8:12 AM Qing Zhao wrote: > > > > > > > > > On Sep 15, 2023, at 3:43 AM, Xi Ruoyao wrote: > > > > > > On Thu, 2023-09-14 at 21:41 +, Qing Zhao wrote: > > CLANG already provided -fsanitize=unsigned-int

Re: Question on -fwrapv and -fwrapv-pointer

On Fri, Sep 15, 2023 at 05:47:08PM +, Qing Zhao wrote: > > > > On Sep 15, 2023, at 1:26 PM, Richard Biener > > wrote: > > > > > > > >> Am 15.09.2023 um 17:37 schrieb Qing Zhao : > >> > >>  > >> > On Sep 15, 2023, at 11:29 AM, Richard Biener > wrote: > > >

Re: [PATCH] Fortran: improve bounds-checking for array sections [PR30802]

Hi Paul, On 9/15/23 11:13, Paul Richard Thomas via Gcc-patches wrote: Hi Harald, The statement, in array_bound_check_elemental is redundant since the call is determined by a more restrictive condition. + if (!(gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)) +return; yeah, this was left over

Re: [PATCH] [RISC-V] fix PR 111259 invalid zcmp mov predicate.

On Fri, 15 Sep 2023 09:37:48 PDT (-0700), Patrick O'Neill wrote: On 9/15/23 01:49, Kito Cheng via Gcc-patches wrote: I guess another solution is using reg_or_subregno instead of REGNO, but that should not catch more cases, and just more run-time check, so this version is LGTM. I tested an equi

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

On Fri, Sep 15, 2023 at 02:08:46PM -0400, Jason Merrill wrote: > On 9/13/23 20:02, Marek Polacek wrote: > > On Wed, Sep 13, 2023 at 05:57:47PM -0400, Jason Merrill wrote: > > > On 9/13/23 16:56, Marek Polacek wrote: > > > > On Tue, Sep 12, 2023 at 05:26:25PM -0400, Jason Merrill wrote: > > > > > On

[Committed] [RISC-V] fix PR 111259 invalid zcmp mov predicate.

Committed - Thanks! Patrick On 9/15/23 13:06, Palmer Dabbelt wrote: On Fri, 15 Sep 2023 09:37:48 PDT (-0700), Patrick O'Neill wrote: On 9/15/23 01:49, Kito Cheng via Gcc-patches wrote: I guess another solution is using reg_or_subregno instead of REGNO, but that should not catch more cases, a

Re: [PATCH] libstdc++: Reduce integer std::to/from_chars symbol sizes

On Wed, 13 Sept 2023 at 23:52, Patrick Palka via Libstdc++ wrote: > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? OK, thanks. > > -- >8 -- > > For std::to_chars: > > The constrained alias __integer_to_chars_result_type seems unnecessary > ever since r10-3080-g28f0075742ed58 got r

[PATCH v2 6/13] libstdc++: Remove dg-options "-std=gnu++20" from and tests

This is v2 of patch 6/13, because I missed three files in the first patch. Tested aarch64-linux. I intend to push this (and the rest of the series) soon. -- >8 -- The testsuite will automatically select C++20 for these tests now, and removing the hardcoded -std option allows them to be tested fo

Re: [Committed] RISC-V: Finish Typing Un-Typed Instructions and Turn on Assert

On 9/11/2023 5:49 PM, Jeff Law via Gcc-patches wrote: On 9/11/23 16:52, Edwin Lu wrote: Updates autovec instruction that was added after last patch and turns on the assert statement to ensure all new instructions have a type. * config/riscv/autovec-opt.md: Update type * config/riscv/

[committed] libstdc++: Fix 29_atomics/headers/atomic/types_std_c++2a_neg.cc for C++23

Tested aarch64-linux. Pushed to trunk. -- >8 -- This test fails when run as C++23 because the PCH includes which declares ::memory_order, invalidating the test's assumptions. Disable PCH so that the test verifies that doesn't declare ::memory_order, as originally intended. Also fix the using-

Re: [PATCH 00/13] libstdc++: Add support for running tests with multiple -std options

On Mon, 11 Sept 2023 at 17:37, Jonathan Wakely via Libstdc++ wrote: > > This patch series replicates the behaviour of the g++ testsuite, so that > libstdc++ tests can easily be run for multiple different -std options in > a single testsuite run. As described in the updated docs, the -std > option

[committed] libstdc++: Add log line to testsuite output

Tested aarch64-linux. Pushed to trunk. This makes it easier to debug the problem when a test isn't running because there's a testsuite_files that doesn't include it. -- >8 -- Write a line to the log when using a testsuite_files file. libstdc++-v3/ChangeLog: * testsuite/libstdc++-dg/con

[committed] libstdc++: Implement C++26 native handles for file streams (P1759R6)

Tested aarch64-linux. Pushed to trunk. -- >8 -- The new __basic_file::native_handle() function can be added for C++11 and above, because the names "native_handle" and "native_handle_type" are already reserved since C++11. Exporting those symbols from the shared library does no harm, even if the f

[committed] libstdc++: Add missing tests for std::basic_filebuf::native_handle()

Tested aarch64-linux. Pushed to trunk. -- >8 -- I forgot to 'git add' these files in the commit that added the new member function to basic_filebuf. libstdc++-v3/ChangeLog: * testsuite/27_io/basic_filebuf/native_handle/char/1.cc: New test. * testsuite/27_io/basic_filebuf/native_

  1   2   >