[Bug fortran/82774] [10/11/12/13/14 Regression] Structure constructor and deferred type parameter character component

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82774 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug fortran/104429] [10/11/12/13/14 Regression] ICE in gfc_conv_variable, at fortran/trans-expr.cc:3056 since r9-2664-g1312bb902382cb48

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104429 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug fortran/103389] [10/11/12/13/14 Regression] ICE in estimate_move_cost, at tree-inline.c:4191 since r9-5784-ga3df90b9672562d0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103389 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug fortran/87946] [10/11/12/13/14 Regression] ICE in gfc_walk_array_ref, at fortran/trans-array.c:10506

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87946 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug target/87496] ICE in aggregate_value_p at gcc/function.c:2046

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87496 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #18

[Bug fortran/100193] [10/11/12/13/14 Regression] ICE in alloc_scalar_allocatable_for_assignment, at fortran/trans-expr.c:10837

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100193 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug fortran/105152] [10/11/12/13/14 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.cc:5647 since r9-5372-gbbf18dc5d248a79a

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105152 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug fortran/103389] [10/11/12/13/14 Regression] ICE in estimate_move_cost, at tree-inline.c:4191 since r9-5784-ga3df90b9672562d0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103389 --- Comment #6 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:6c95fe9bc0553743098eeaa739f14b885050fa42 commit r14-870-g6c95fe9bc0553743098eeaa739f14b885050fa42 Author: Paul Thomas Date: Tue

[Bug fortran/87946] [10/11/12/13/14 Regression] ICE in gfc_walk_array_ref, at fortran/trans-array.c:10506

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87946 --- Comment #9 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:6c95fe9bc0553743098eeaa739f14b885050fa42 commit r14-870-g6c95fe9bc0553743098eeaa739f14b885050fa42 Author: Paul Thomas Date: Tue

[Bug target/87496] ICE in aggregate_value_p at gcc/function.c:2046

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87496 --- Comment #17 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:6c95fe9bc0553743098eeaa739f14b885050fa42 commit r14-870-g6c95fe9bc0553743098eeaa739f14b885050fa42 Author: Paul Thomas Date: Tue

[Bug fortran/82774] [10/11/12/13/14 Regression] Structure constructor and deferred type parameter character component

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82774 --- Comment #11 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:6c95fe9bc0553743098eeaa739f14b885050fa42 commit r14-870-g6c95fe9bc0553743098eeaa739f14b885050fa42 Author: Paul Thomas Date: Tue

[Bug fortran/104429] [10/11/12/13/14 Regression] ICE in gfc_conv_variable, at fortran/trans-expr.cc:3056 since r9-2664-g1312bb902382cb48

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104429 --- Comment #5 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:6c95fe9bc0553743098eeaa739f14b885050fa42 commit r14-870-g6c95fe9bc0553743098eeaa739f14b885050fa42 Author: Paul Thomas Date: Tue

[Bug fortran/105152] [10/11/12/13/14 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.cc:5647 since r9-5372-gbbf18dc5d248a79a

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105152 --- Comment #5 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:6c95fe9bc0553743098eeaa739f14b885050fa42 commit r14-870-g6c95fe9bc0553743098eeaa739f14b885050fa42 Author: Paul Thomas Date: Tue

[Bug fortran/100193] [10/11/12/13/14 Regression] ICE in alloc_scalar_allocatable_for_assignment, at fortran/trans-expr.c:10837

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100193 --- Comment #5 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:6c95fe9bc0553743098eeaa739f14b885050fa42 commit r14-870-g6c95fe9bc0553743098eeaa739f14b885050fa42 Author: Paul Thomas Date: Tue

Re: [Testsuite] Skip -fdelete-null-pointer-check tests if target keeps_null_pointer_checks

On 5/14/23 23:06, SenthilKumar.Selvaraj--- via Gcc-patches wrote: Hi, When running regression tests related to https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616772.html, I noticed a bunch of failures because some tests explicitly pass in -fdelete-null-pointer-checks, even if the

Re: Re: [PATCH V7] VECT: Add decrement IV support in Loop Vectorizer

>> The examples are good, but this one made me wonder: why is the >> adjustment made to the limit (namely 16, the gap between _39 and _41) >> different from the limits imposed by the MIN_EXPR (32)? And I think >> the answer is that: >> - _47 counts the number of elements processed by the loop in

Re: [gcc13 backport] RISCV: Inline subword atomic ops

On 5/9/23 10:01, Patrick O'Neill wrote: Ping. OK for backporting. Sorry for the delay. jeff

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #13 from Sam James --- the OOB read seems to go away with --enable-checking=yes,rtl,extra (previously had --enable-checking=release)...? (at least for 13)

Re: [PATCH] riscv: Add autovectorization tests for binary integer

On 5/15/23 03:15, juzhe.zh...@rivai.ai wrote: I think it is the issue of include file. Kito may know the better the solution instead of changing stdint.h into stdint-gcc.h. I think that's the only solution right now. I'm not keen to open up the multilib can of worms. Consider a patch

Re: [PATCH v9] RISC-V: Add the 'zfa' extension, version 0.2

On 5/15/23 07:16, Jin Ma wrote: This patch adds the 'Zfa' extension for riscv, which is based on: https://github.com/riscv/riscv-isa-manual/commits/zfb The binutils-gdb for 'Zfa' extension: https://sourceware.org/pipermail/binutils/2023-April/127060.html What needs special explanation is:

Re: [PATCH v9] RISC-V: Add the 'zfa' extension, version 0.2

On 5/15/23 07:30, jinma wrote: According to Jeff's review feedback, the issues regarding UNSPEC's implementation of round, ceil, nearbyint, etc. still need to be determined: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617706.html source:

Re: [PATCH v8] RISC-V: Add the 'zfa' extension, version 0.2.

On 5/6/23 06:53, jinma wrote: diff --git a/gcc/config/riscv/iterators.md b/gcc/config/riscv/iterators.md index 9b767038452..c81b08e3cc5 100644 --- a/gcc/config/riscv/iterators.md +++ b/gcc/config/riscv/iterators.md @@ -288,3 +288,8 @@ (define_int_iterator QUIET_COMPARISON [UNSPEC_FLT_QUIET

Re: [PATCH] RISC-V: Add rounding mode operand for floating point instructions

On 5/15/23 07:54, 钟居哲 wrote: I don't know why we should not add frm vfsqrt.v since I saw topper (LLVM maintainer) said we should not add frm into vsqrt.v. Maybe kito knows the reason ? I'm pretty sure this is referring to the estimator. The documentation is very clear that the sqrt

[Bug tree-optimization/101805] Max -> bool0 | bool1 Min -> a & b

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

[Bug tree-optimization/109424] ~((x > y) ? x : y) produces two not instructions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109424 --- Comment #7 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:b06cfb62229f17eca59fa4aabf853d7e17e2327b commit r14-868-gb06cfb62229f17eca59fa4aabf853d7e17e2327b Author: Andrew Pinski Date:

[Bug tree-optimization/107888] [12/13/14 Regression] Missed min/max transformation in phiopt due to VRP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107888 --- Comment #11 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:b06cfb62229f17eca59fa4aabf853d7e17e2327b commit r14-868-gb06cfb62229f17eca59fa4aabf853d7e17e2327b Author: Andrew Pinski Date:

[Bug c++/109870] Miscomputation of return type of unevaluated lambda in type alias in template context

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109870 --- Comment #1 from Andrew Pinski --- Most likely a dup of a bug that PR 107430 depends on.

RE: [PATCH V2] RISC-V: Add FRM and rounding mode operand into floating point intrinsics

Committed, thanks Jeff. Pan -Original Message- From: Gcc-patches On Behalf Of Jeff Law via Gcc-patches Sent: Tuesday, May 16, 2023 11:27 AM To: juzhe.zh...@rivai.ai; gcc-patches Cc: Kito.cheng ; palmer ; Robin Dapp Subject: Re: [PATCH V2] RISC-V: Add FRM and rounding mode operand

[Bug c++/109870] New: Miscomputation of return type of unevaluated lambda in type alias in template context

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109870 Bug ID: 109870 Summary: Miscomputation of return type of unevaluated lambda in type alias in template context Product: gcc Version: 14.0 Status: UNCONFIRMED

Re: [PATCH V2] RISC-V: Add FRM and rounding mode operand into floating point intrinsics

On 5/15/23 19:02, juzhe.zh...@rivai.ai wrote: Ping。 Is it Ok for trunk ? I have double checked the floating-point instructions needed FRM. Yes, this is OK for the trunk. Thanks, jeff

Re: [PATCH] MATCH: [PR109424] Simplify min/max of boolean arguments

On 5/15/23 19:36, Andrew Pinski via Gcc-patches wrote: This is version 2 of https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577394.html which does not depend on adding gimple_truth_valued_p at this point. Instead will use zero_one_valued_p which is already used for mult

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858 --- Comment #6 from Kewen Lin --- (In reply to Hongtao.liu from comment #5) > (In reply to Kewen Lin from comment #3) > > (In reply to Hongtao.liu from comment #2) > > > Does https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617431.html help?

[Bug tree-optimization/90087] Suboptimal codegen for x < 0 ? x - INT_MIN : x

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90087 --- Comment #3 from Andrew Pinski --- THis way with type_min and type_max filled out correctly. (simplify (cond (lt @0 integer_zero_p) (minus @0 INTEGER_CST@1) @0) (if (TYPE_SIGNED (type) && wi::to_widest(@0) == type_min(@0)) (bit_ior @0 {

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858 --- Comment #5 from Hongtao.liu --- (In reply to Kewen Lin from comment #3) > (In reply to Hongtao.liu from comment #2) > > Does https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617431.html help? > > Sorry, I just measured those degraded

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858 --- Comment #4 from Hongtao.liu --- Created attachment 55091 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55091=edit Only use NO_REGS in cost calculation when !hard_regno_mode_ok for GENERAL_REGS and mode.

[Bug tree-optimization/109869] New: comparing SCHAR_MIN and SCHAR_MAX but with widden type could be optimized better

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109869 Bug ID: 109869 Summary: comparing SCHAR_MIN and SCHAR_MAX but with widden type could be optimized better Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug c/109863] RFE: more consistent flex array initialization: lift static storage requirement in gnu2x

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109863 --- Comment #2 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #1) > Note that the entire "initializing a flexible array member" thing is a GNU > extension and not supported by the standard. So GCC is free to support the > constexpr

[Bug c/109863] RFE: more consistent flex array initialization: lift static storage requirement in gnu2x

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109863 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #1

[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77899 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug tree-optimization/101805] Max -> bool0 | bool1 Min -> a & b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101805 Andrew Pinski changed: What|Removed |Added Keywords||patch URL|

[PATCH] MATCH: [PR109424] Simplify min/max of boolean arguments

This is version 2 of https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577394.html which does not depend on adding gimple_truth_valued_p at this point. Instead will use zero_one_valued_p which is already used for mult simplifications to make sure that we only have [0,1] rather having the

RE: [PATCH v3] Machine_Mode: Extend machine_mode from 8 to 16 bits

Kindly ping for this PATCH v3. Pan -Original Message- From: Li, Pan2 Sent: Saturday, May 13, 2023 9:13 PM To: gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Li, Pan2 ; Wang, Yanzhang ; jeffreya...@gmail.com; rguent...@suse.de; richard.sandif...@arm.com

RE: [PATCH] RISC-V: Support RVV VREINTERPRET from v{u}int*_t to vbool1_t

Kindly ping for this PATCH, . Pan From: Li, Pan2 Sent: Monday, May 15, 2023 11:25 AM To: juzhe.zh...@rivai.ai; gcc-patches Cc: Kito.cheng ; Wang, Yanzhang Subject: RE: [PATCH] RISC-V: Support RVV VREINTERPRET from v{u}int*_t to vbool1_t Thanks Juzhe. Let’s wait kito’s suggestion. Pan

Re: [PATCH V2] RISC-V: Add FRM and rounding mode operand into floating point intrinsics

Ping。 Is it Ok for trunk ? I have double checked the floating-point instructions needed FRM. Thanks. juzhe.zh...@rivai.ai From: juzhe.zhong Date: 2023-05-15 22:53 To: gcc-patches CC: kito.cheng; palmer; rdapp.gcc; jeffreyalaw; Juzhe-Zhong Subject: [PATCH V2] RISC-V: Add FRM and rounding

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #12 from Andrew Pinski --- Jakub, assign this to me if you think we should go down that route unless you want to take the patch further.

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #11 from Andrew Pinski --- Created attachment 55090 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55090=edit Patch which I came up with This patch adds back zero_sized_field_decl but keeps the call to is_empty_type too.

[committed] c: Ignore _Atomic on function return type for C2x

For C2x it was decided that _Atomic would be completely ignored on function return types (just as was done for qualifiers in C11 DR#423), to eliminate the potential for an rvalue returned by a function having _Atomic-qualified type when an rvalue resulting from lvalue-to-rvalue conversion could

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #10 from Sam James --- fwiw, on glibc, I don't get the oob read w/ valgrind but still the ICE as you've already found.

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #9 from Jakub Jelinek --- The ICE started with r13-436-gaf34279921f4bb95b07c0be but the undesirable store is there already since r12-2975-g32c3a75390623a0470df52.

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > That might have been caused by r12-1150-g34aae6b561871d . I will look into > it soon because we should not be emitting an assignment here ... Yes it was

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #6 from Andrew Pinski --- See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806#c15 .

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #5 from Andrew Pinski --- A little more reduced: ``` struct ClockImpl { virtual void addRef(); long tv_nsec; int : 0; }; void f() { ClockImpl b{}; } ``` So maybe this is a gimplifier issue producing the assignment to the

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 --- Comment #16 from Sam James --- Filed my musl one as PR109868, sorry for clogging up this one!

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #4 from Andrew Pinski --- Hmm: D.2948._startTime.D.2792 = 0; That seems wrong. Reduced further: ``` struct SimpleRefCounted { virtual void addRef(); }; struct ClockImpl : SimpleRefCounted { long tv_nsec; int : 0; }; void

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 Andrew Pinski changed: What|Removed |Added Component|c++ |tree-optimization Known to fail|

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 --- Comment #15 from Jakub Jelinek --- That ICE is because layout_class_type calls c_build_bitfield_integer_type with width of 0 and that type is then seen by ranger for some reason: #7 0x00c4eee1 in layout_class_type (t=,

[Bug c++/109868] [13/14 regression] ICE: segmentation fault when building small C++ program

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #2 from Sam James --- Created attachment 55089 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55089=edit clock.ii (reduced)

[Bug c++/109868] [13/14 regression] ICE: segmentation fault when building small C++ program

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #1 from Sam James --- Created attachment 55088 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55088=edit clock.ii.orig

[Bug c++/109868] New: [13/14 regression] ICE: segmentation fault when building small C++ program

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 Bug ID: 109868 Summary: [13/14 regression] ICE: segmentation fault when building small C++ program Product: gcc Version: 14.0 Status: UNCONFIRMED Severity:

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 --- Comment #14 from Sam James --- (In reply to Alexander Monakov from comment #13) > The 128KB stack size is for *secondary* threads on musl (i.e. those created > via pthread_create). The main thread has the same stack as on glibc (GCC >

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org ---

[Bug fortran/109865] different results when routine moved inside the contains statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #8 from GARY.WHITE at ColoState dot edu --- I just tried to send you a zip file with all the code and instructions (see below), but it is over 6Mb in size, and was rejected. Where can I put it that you can access it? I have put

[Bug fortran/109865] different results when routine moved inside the contains statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #7 from GARY.WHITE at ColoState dot edu --- Sorry I can't simplify this down to a nice compact piece of code, but ... In the attached test_case.zip file are all the *.f90 files, makefile, and some library files that work on ubuntu

[Bug tree-optimization/101805] Max -> bool0 | bool1 Min -> a & b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101805 Andrew Pinski changed: What|Removed |Added Keywords|patch |

[Bug c++/109867] New: -Wswicht-default reports missing default in coroutine

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109867 Bug ID: 109867 Summary: -Wswicht-default reports missing default in coroutine Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug tree-optimization/109720] -Wmaybe-uninitialized triggering when I can see no path that would allow it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720 --- Comment #7 from Paul Smith --- Just to note this code also throws this warning in GCC 12.3 but it doesn't complain in GCC 11.3 which is what I was using before.

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 Sam James changed: What|Removed |Added CC||aldyh at gcc dot gnu.org See

[committed] c: Update __has_c_attribute values for C2x

WG14 decided that __has_c_attribute should return the same value (equal to the intended __STDC_VERSION__ value) for all standard attributes in C2x, with values associated with when an attribute was added to the working draft (or had semantics added or changed in the working draft) only being used

[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org ---

[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Scot Breitenfeld from comment #3) > I guess the issue is whether marking TYPE(C_PTR) as CLOBBER is correct. I > looked through the 2018 standard and could not locate anything that >

Re: Re: [PATCH V7] VECT: Add decrement IV support in Loop Vectorizer

Hi, Richard. >> Easier to read as: >> _41 = _40 - 16 >> (which might not be valid gimple, but pseudocode is good enough). OK. >> The difficulty with this is that the len_load* and len_store* >>optabs currently say that the behaviour is undefined if the >>length argument is greater than the

[PATCH V9] VECT: Add decrement IV support in Loop Vectorizer

From: Ju-Zhe Zhong his patch implement decrement IV for length approach in loop control. Address comment from kewen that incorporate the implementation inside "vect_set_loop_controls_directly" instead of a standalone function. Address comment from Richard using MIN_EXPR to handle these 3

Re: [PATCH] Turn on LRA on all targets

"Maciej W. Rozycki" writes: > On Sun, 23 Apr 2023, Segher Boessenkool wrote: > >> > There are extra ICEs in regression testing and code quality is poor; cf. >> > . >> >> Do you have something you can show for this? Maybe

Re: [PATCH] Turn on LRA on all targets

On Sun, 23 Apr 2023, Segher Boessenkool wrote: > > There are extra ICEs in regression testing and code quality is poor; cf. > > . > > Do you have something you can show for this? Maybe in a PR? I have filed no PRs as I

[Bug testsuite/66005] libgomp make check time is excessive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 --- Comment #14 from Thomas Schwinge --- (In reply to Eric Gallager from comment #12) > Note that there's a gnulib module for flock: > https://www.gnu.org/software/gnulib/manual/html_node/flock.html I'd see that one -- but it also says: "the

[Bug fortran/109865] different results when routine moved inside the contains statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to gary.wh...@colostate.edu from comment #5) > (In reply to Steve Kargl from comment #4) > > I assume you've also tried with -fcheck=all. > > Your report states you're using og12. If

[Bug fortran/109865] different results when routine moved inside the contains statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #5 from GARY.WHITE at ColoState dot edu --- (In reply to Steve Kargl from comment #4) > On Mon, May 15, 2023 at 07:11:17PM +, Gary.White at ColoState dot edu > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 > >

[Bug testsuite/66005] libgomp make check time is excessive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 --- Comment #13 from Jakub Jelinek --- And fcntl in tclx. Anyway, I think choosing between flock(1) and some python file locking would be better than using perl which is only needed in maintainer mode and not otherwise.

Re: [PATCH 0/3] Refactor memory block operations

On 5/15/23 09:17, Stefan Schulze Frielinghaus wrote: > Bootstrapped and regtested. Ok for mainline? > > Stefan Schulze Frielinghaus (3): > s390: Refactor block operation cpymem > s390: Add block operation movmem > s390: Refactor block operation setmem > > gcc/config/s390/s390-protos.h

Re: More C type errors by default for GCC 14

On 5/15/23, Richard Earnshaw (lists) via Gcc wrote: > On 10/05/2023 03:38, Eli Zaretskii via Gcc wrote: >>> From: Arsen Arsenović >>> Cc: Eli Zaretskii , Jakub Jelinek , >>> jwakely@gmail.com, gcc@gcc.gnu.org >>> Date: Tue, 09 May 2023 22:21:03 +0200 >>> The concern is using the good

Re: [PATCH] aarch64: Add SVE instruction types

Hi, Kyrill. I wasn’t aware of your previous patch. Could you clarify why you considered creating an SVE specific type attribute instead of reusing the common one? I really liked the iterators that you created; I’d like to use them. Do you have specific examples which you might want to

[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861 --- Comment #3 from Scot Breitenfeld --- I see the same issue with NAG, regardless of the optimization level. Our CI testing had missed it because this was a parallel test, and we don't test parallel with NAG. I guess the issue is whether

[Bug testsuite/66005] libgomp make check time is excessive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 --- Comment #12 from Eric Gallager --- Note that there's a gnulib module for flock: https://www.gnu.org/software/gnulib/manual/html_node/flock.html

Re: [PATCH] aarch64: Add SVE instruction types

Hi, Richard. My criteria were very much (a). In some cases though, a particular instruction could have variations that others in its natural group didn’t, when if seemed sensible to create a specific description for this instruction, even if its base form shares resources with other

Re: [wish] Flexible array members in unions

> On May 12, 2023, at 2:16 AM, Richard Biener via Gcc wrote: > > On Thu, May 11, 2023 at 11:14 PM Kees Cook via Gcc wrote: >> >> On Thu, May 11, 2023 at 08:53:52PM +, Joseph Myers wrote: >>> On Thu, 11 May 2023, Kees Cook via Gcc wrote: >>> On Thu, May 11, 2023 at 06:29:10PM +0200,

Re: [PATCH v2] libstdc++: Do not use pthread_mutex_clocklock with ThreadSanitizer

On Thu, May 11, 2023 at 1:52 PM Jonathan Wakely wrote: > On Thu, 11 May 2023 at 13:42, Jonathan Wakely wrote: > >> >> >> On Thu, 11 May 2023 at 13:19, Mike Crowe wrote: >> >>> However, ... >>> >>> > > diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 >>> > > index

Re: [PATCH V7] VECT: Add decrement IV support in Loop Vectorizer

juzhe.zh...@rivai.ai writes: > From: Juzhe-Zhong > > This patch implement decrement IV for length approach in loop control. > > Address comment from kewen that incorporate the implementation inside > "vect_set_loop_controls_directly" instead of a standalone function. > > Address comment from

[Bug fortran/109865] different results when routine moved inside the contains statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #4 from Steve Kargl --- On Mon, May 15, 2023 at 07:11:17PM +, Gary.White at ColoState dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 > (In reply to kargl from comment #2) > > (In reply to

[Bug fortran/109865] different results when routine moved inside the contains statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #3 from GARY.WHITE at ColoState dot edu --- (In reply to kargl from comment #2) > (In reply to gary.wh...@colostate.edu from comment #0) > > Created attachment 55087 [details] > > set of subroutines where moving mc11ad inside the

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856 Thomas Schwinge changed: What|Removed |Added CC||redi at gcc dot gnu.org,

Back to requiring "Perl version 5.6.1 (or later)" [PR82856] (was: Update GCC to autoconf 2.69, automake 1.15.1)

Hi! On 2018-10-31T17:04:46+, Joseph Myers wrote: > On Wed, 31 Oct 2018, Thomas Koenig wrote: >> Am 31.10.18 um 04:26 schrieb Joseph Myers: >> > This patch (diffs to generated files omitted below) updates GCC to use >> > autoconf 2.69 and automake 1.15.1. >> >> I think this should fix PR

Re: [aarch64] Code-gen for vector initialization involving constants

Prathamesh Kulkarni writes: > Hi Richard, > After committing the interleave+zip1 patch for vector initialization, > it seems to regress the s32 case for this patch: > > int32x4_t f_s32(int32_t x) > { > return (int32x4_t) { x, x, x, 1 }; > } > > code-gen: > f_s32: > moviv30.2s, 0x1 >

[Bug fortran/109865] different results when routine moved inside the contains statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org ---

[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861 --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #1) > I think that you might want to cross-check your testcase with the NAG > compiler, or some other compiler which provides a means to initialize > INTENT(OUT)

[Bug rtl-optimization/109866] New: Sometimes using sub/test instead just test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109866 Bug ID: 109866 Summary: Sometimes using sub/test instead just test Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement

[Bug testsuite/66005] libgomp make check time is excessive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 --- Comment #11 from Thomas Schwinge --- (In reply to myself from comment #10) > Could we easily build a portable 'flock'-like using 'fcntl' locking > primitives? (, for example.)

[Bug fortran/109865] different results when routine moved inside the contains statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-05-15

[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109861 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-05-15

Ping: [PATCH V5] PR target/105325: Fix constraint issue with power10 fusion

Ping both patches: Patch #1, rewrite genfusion.pl's code for load and compare immediate fusion to be more readable. This patch produces the same output as the current sources. | Date: Wed, 10 May 2023 11:38:55 -0400 | Subject: Re: [PATCH V5, 1/2] PR target/105325: Rewrite genfusion.pl's

  1   2   3   4   >