[Bug target/114861] [14/15 Regression] LoongArch: ICE building the kernel with -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861 Xi Ruoyao changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/114861] [14/15 Regression] LoongArch: ICE building the kernel with -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861 --- Comment #8 from GCC Commits --- The releases/gcc-14 branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:3e04b6f6ba568e6183e8aa8223d4156234503843 commit r14-10142-g3e04b6f6ba568e6183e8aa8223d4156234503843 Author: Xi Ruoyao Date:

[Bug target/114861] [14/15 Regression] LoongArch: ICE building the kernel with -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861 --- Comment #7 from GCC Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:140124ad54eef88ca87909f63aedc8aaeacefc65 commit r15-11-g140124ad54eef88ca87909f63aedc8aaeacefc65 Author: Xi Ruoyao Date: Fri Apr 26

[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426 --- Comment #15 from Jerry DeLisle --- (In reply to Matt Thompson from comment #14) > Never mind. I'll send attachment to Jerry offline. It's too big for here. Got it. It works quite well for our purposes.

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 for C++11

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865 --- Comment #13 from Peter Dimov --- (In reply to Andrew Pinski from comment #10) > #if __cplusplus >= 201402L && __has_builtin(__builtin_clear_padding) > if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Tp>()) >

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 for C++11

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865 --- Comment #12 from Andrew Pinski --- (In reply to Peter Dimov from comment #11) > So, basically, C++14 and above initialize the padding of > > ``` > std::atomic state{{ 0, 0x }}; > ``` > > in `main` to zero, which masks the problem

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 for C++11

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865 --- Comment #11 from Peter Dimov --- So, basically, C++14 and above initialize the padding of ``` std::atomic state{{ 0, 0x }}; ``` in `main` to zero, which masks the problem in `generate`. (The problem in `generate` still exists

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 for C++11

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865 Andrew Pinski changed: What|Removed |Added Summary|[13/14/15 Regression] |[13/14/15 Regression]

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865 --- Comment #9 from Peter Dimov --- Oh, my mistake. C++14 does mov QWORD, and C++11 does mov WORD.

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865 --- Comment #8 from Peter Dimov --- (In reply to Andrew Pinski from comment #6) > No it is dependent on the standard level. C++11 fails but C++14, C++17 and > C++20 all pass. That's interesting because I see basically no difference in the

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865 --- Comment #7 from Andrew Pinski --- The problem is only with auto atomic variables. Looks like the padding there is not being zeroed for -std=c++11 ...

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865 --- Comment #6 from Andrew Pinski --- (In reply to Peter Dimov from comment #4) > but I believe it's independent of standard level and address model. No it is dependent on the standard level. C++11 fails but C++14, C++17 and C++20 all pass.

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

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

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865 --- Comment #5 from Andrew Pinski --- Created attachment 58053 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58053=edit testcase

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865 --- Comment #4 from Peter Dimov --- This https://raw.githubusercontent.com/boostorg/uuid/feature/gcc_pr_114865/test/test_gcc_pr114865.cpp exhibits the problem for me on GCC 13/14. I'm only seeing the hang with -std=c++11 -m32 in the CI run

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-04-26

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865 Andrew Pinski changed: What|Removed |Added Summary|std::atomic::compare_exc |[13/14/15 Regression]

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #16 from Christophe Lyon --- Thanks for the suggestion, this works. I've posted the patch + testcase: https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650086.html

[Bug libstdc++/106852] Implement C++23 P2465R3 Standard Library Modules std and std.compat

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106852 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement

[Bug middle-end/112976] expand_gimple_stmt_1 vs gimple_assign_nontemporal_move_p vs SSA_NAME on lhs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112976 --- Comment #7 from Andrew Pinski --- Patches posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650085.html https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650084.html

[Bug target/114843] aarch64: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 Andrew Pinski changed: What|Removed |Added Attachment #58043|0 |1 is obsolete|

[Bug tree-optimization/113673] [12/13/14/15 Regression] ICE: verify_flow_info failed: BB 5 cannot throw but has an EH edge with -Os -finstrument-functions -fnon-call-exceptions -ftrapv

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113673 Roger Sayle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #15 from Jakub Jelinek --- https://developer.arm.com/documentation/101028/0012/14--M-profile-Vector-Extension--MVE--intrinsics suggests that it is a UB if all the bits for a single element aren't the same (i.e. false is all 0s, true

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #14 from Christophe Lyon --- Created attachment 58050 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58050=edit patch proposal Here is the patch I propose.

[Bug c++/114685] [modules] ICE when exporting a type through a different alias then one declared in GMF

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114685 --- Comment #4 from m.cencora at gmail dot com --- I've stumbled upon a related error when trying to export std::vector after inclusion of in GMF: module; namespace std { class vector; namespace __format { using std::vector; } } export

[Bug c/114870] New: stddef.h problem with -Wsystem-headers on Fedora 40

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114870 Bug ID: 114870 Summary: stddef.h problem with -Wsystem-headers on Fedora 40 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c/114869] New: GCC says nullptr_t is a C built in but it should be in

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114869 Bug ID: 114869 Summary: GCC says nullptr_t is a C built in but it should be in Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug middle-end/114855] ICE: Segfault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855 --- Comment #5 from jeremy rutman --- Using gcc 14.0.1 20240117 (experimental) [master r14-8187-gb00be6f1576] I was able to compile when not using any flags: $ /usr/lib/gcc-snapshot/bin/cc -c aesDecrypt.c -o aesDecrypt.o But when using the

[Bug libstdc++/114865] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865 --- Comment #2 from Peter Dimov --- The issue is also present for GCC 14 on Ubuntu 24.04: https://github.com/boostorg/uuid/actions/runs/8853249656/job/24313667955

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

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

[Bug fortran/102620] [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865 since r12-1233-gd514626ee2566c68

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102620 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED

[Bug c++/114868] New: [modules] func declared in GMF and exported via using-decl in module partition is not actually exported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114868 Bug ID: 114868 Summary: [modules] func declared in GMF and exported via using-decl in module partition is not actually exported Product: gcc Version: 14.0

[Bug fortran/103716] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15964 since r9-3803-ga5fbc2f36a291cbe

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103716 --- Comment #11 from GCC Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:b482968801158116dd8ba3b15a4c29143b2a423a commit r12-10398-gb482968801158116dd8ba3b15a4c29143b2a423a Author: Paul Thomas

[Bug c++/114867] New: [modules] name lookup issues when a function overload set is exported from GMF

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114867 Bug ID: 114867 Summary: [modules] name lookup issues when a function overload set is exported from GMF Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug libstdc++/114817] Wrong codegen for std::copy of "trivially copyable but not trivially assignable" type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114817 --- Comment #3 from Arthur O'Dwyer --- https://github.com/boostorg/container/issues/153 , from 2020, is another similar issue. There, boost::container::vector had assumed that if __has_trivial_copy(T) and is_copy_constructible_v, then T could

[Bug target/114843] aarch64: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 --- Comment #18 from Andrew Pinski --- (In reply to Wilco from comment #17) > So I don't believe you should change aarch64_pop_regs at all - it's too late > to change things and just adds unnecessary complexity and more bugs. The > best option

[Bug fortran/102620] [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865 since r12-1233-gd514626ee2566c68

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102620 --- Comment #12 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #11) > It would be splendid if you would backport the patch. In the last week or > so, I have built up quite a list of backports to do, which I will attend

Re: for discussion: should we close all the Java-related bugs?

On Fri, Apr 26, 2024 at 11:28 AM Abe Skolnik via Gcc-bugs wrote: > > Dear all, > > AFAIK, GCJ has been dead for _years_... quoting > : "As of GCC 7, the GCC Java frontend and > associated libjava runtime library have been removed from GCC. The > information on

for discussion: should we close all the Java-related bugs?

Dear all, AFAIK, GCJ has been dead for _years_...  quoting : "As of GCC 7, the GCC Java frontend and associated libjava runtime library have been removed from GCC. The information on this page is kept here for reference but only applies to GCC 6 and earlier." ...

[Bug fortran/114859] [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 --- Comment #10 from Jakub Jelinek --- Ah, the following shows what is happening and shows similar IL changes in the *.optimized dump: module m1 type amg_d_base_solver_type contains procedure, pass(sv) :: free => amg_d_base_solver_free

[Bug tree-optimization/99475] [11 Regression] bogus -Warray-bounds accessing an array element of empty structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99475 Siddhesh Poyarekar changed: What|Removed |Added CC||siddhesh at gcc dot gnu.org ---

[Bug fortran/114859] [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 --- Comment #9 from Jakub Jelinek --- I see there roughly module m1 type amg_d_base_solver_type contains procedure, pass(sv) :: apply_v => amg_d_base_solver_apply_vect procedure, pass(sv) :: apply_a => amg_d_base_solver_apply end

[Bug libstdc++/114866] New: & out_ptr in freestanding

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114866 Bug ID: 114866 Summary: & out_ptr in freestanding Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #13 from Jakub Jelinek --- (In reply to Christophe Lyon from comment #12) > (In reply to Jakub Jelinek from comment #11) > > So, tried this under the debugger. All VALID_MVE_PRED_MODE modes have the > > same size, 2 bytes, so I'd

[Bug target/114843] aarch64: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 --- Comment #17 from Wilco --- (In reply to Andrew Pinski from comment #16) > Patch posted with all of the testcases included: > https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650080.html Not nearly enough testcases... What about: void

[Bug libstdc++/114865] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865 --- Comment #1 from Peter Dimov --- > The problem may well be inside libatomic, of course; I have no way to tell. Narrator: but he did, in fact, have a way to tell. This is a GHA run with GCC 9 to 13 tested on both Ubuntu 23.04 and Ubuntu

[Bug target/112304] cinc is not being used for (small) constant

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

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #12 from Christophe Lyon --- (In reply to Jakub Jelinek from comment #11) > So, tried this under the debugger. All VALID_MVE_PRED_MODE modes have the > same size, 2 bytes, so I'd go with > else if (VALID_MVE_PRED_MODE (mode)) >

[Bug target/114272] SCHEDULER_IDENT incorrect for Cortex-A520 and Cortex-A510

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114272 Richard Ball changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug target/114272] SCHEDULER_IDENT incorrect for Cortex-A520 and Cortex-A510

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114272 --- Comment #6 from GCC Commits --- The releases/gcc-12 branch has been updated by Richard Ball : https://gcc.gnu.org/g:751a0f54345b7e037db7f0389c19c1f87e0ae4de commit r12-10397-g751a0f54345b7e037db7f0389c19c1f87e0ae4de Author: Richard Ball

[Bug target/114272] SCHEDULER_IDENT incorrect for Cortex-A520 and Cortex-A510

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114272 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Ball : https://gcc.gnu.org/g:28b3b8a2fe55521a43f3710cf6ced1ab63f1ea03 commit r13-8654-g28b3b8a2fe55521a43f3710cf6ced1ab63f1ea03 Author: Richard Ball

[Bug libstdc++/111258] std::string cannot to be moved in constant evaluated expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111258 --- Comment #4 from Patrick Palka --- Many of these testcases (from here and the related PRs) are now accepted by GCC 14 after r14-10134.

[Bug fortran/114859] [14 Regression] Seeing new segmentation fault in same_type_as since r14-9752

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 --- Comment #8 from Jakub Jelinek --- The upstream sources are: https://github.com/sfilippone/amg4psblas/archive/refs/tags/v1.1.2.tar.gz https://github.com/sfilippone/psblas3/archive/refs/tags/v3.8.1-2.tar.gz

[Bug target/114843] aarch64: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 --- Comment #16 from Andrew Pinski --- Patch posted with all of the testcases included: https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650080.html

[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630 --- Comment #6 from Patrick Palka --- (In reply to Nathaniel Shead from comment #5) > That said, my version doesn't actually solve the underlying issue: my > adjustment of your testcase to put instantiations into the module purview > (and force

[Bug fortran/114859] [14 Regression] Seeing new segmentation fault in same_type_as since r14-9752

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 --- Comment #7 from Jakub Jelinek --- Created attachment 58047 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58047=edit pr114859-1.tar.xz Another module. Unfortunately, the last module is too large for the 1M limit. It can be grabbed

[Bug tree-optimization/114864] [12/13/14/15 regression] wrong code at -O1 with "-fno-tree-dce -fno-tree-fre" on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114864 --- Comment #4 from Eric Botcazou --- Another instance is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453

[Bug fortran/114859] [14 Regression] Seeing new segmentation fault in same_type_as since r14-9752

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 --- Comment #6 from Jakub Jelinek --- Created attachment 58046 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58046=edit pr114859.tar.xz Testcase + one module. I was using ./f951 -quiet -I . amg_d_hierarchy_bld.f90 -m64 -march=x86-64

[Bug fortran/102003] [PDT] Length of character component not simplified

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102003 --- Comment #7 from GCC Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:8ad460ca8824f7e29e38a63f9cb4a9a3b96d506f commit r12-10396-g8ad460ca8824f7e29e38a63f9cb4a9a3b96d506f Author: Andre

[Bug fortran/114859] [14 Regression] Seeing new segmentation fault in same_type_as since r14-9752

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

[Bug target/114861] [14/15 Regression] LoongArch: ICE building the kernel with -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861 Xi Ruoyao changed: What|Removed |Added Last reconfirmed||2024-04-26 Status|UNCONFIRMED

[Bug tree-optimization/114864] [12/13/14/15 regression] wrong code at -O1 with "-fno-tree-dce -fno-tree-fre" on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114864 --- Comment #3 from Eric Botcazou --- Yes, this is a known issue in SRA, see PR optimization/111873, but it apparently shows up only with nonsensical combinations of switches so, well...

[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426 --- Comment #14 from Matt Thompson --- Never mind. I'll send attachment to Jerry offline. It's too big for here.

[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426 --- Comment #13 from Matt Thompson --- Okay I have a new reproducer that I'll attach here. It uses the random names. I see the same behavior: IFX 2024.1: Number of Modules | Build Time - | -- 10 |

[Bug libstdc++/114865] New: std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865 Bug ID: 114865 Summary: std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04 Product: gcc Version: 13.2.0 Status: UNCONFIRMED

[Bug fortran/114859] Seeing new segmentation fault in same_type_as

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 --- Comment #4 from Jakub Jelinek --- LTO doesn't seem to make a difference. And without LTO bisection points at openmpi-build/amgprec/impl/amg_d_hierarchy_bld.o when this is compiled with r14-9704 even when all other sources are compiled with

[Bug tree-optimization/110490] tree-ssa/clz-* and tree-ssa/ctz-* fail on s390x with arch14 (expression_expensive_p not handling if there is wider clz/ctz/popcount optab)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110490 Stefan Schulze Frielinghaus changed: What|Removed |Added CC||stefansf at gcc dot

[Bug libstdc++/114863] std::format applying grouping to nan's and inf's

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863 --- Comment #3 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a0bc71e480132a528a4869c1cd7863f709768c53 commit r15-5-ga0bc71e480132a528a4869c1cd7863f709768c53 Author: Jonathan Wakely Date:

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #11 from Jakub Jelinek --- So, tried this under the debugger. All VALID_MVE_PRED_MODE modes have the same size, 2 bytes, so I'd go with else if (VALID_MVE_PRED_MODE (mode)) { /* unsigned short arguments to functions get

[Bug target/114860] [14/15 regression] [aarch64] 511.povray regresses by ~5.5% with -O3 -flto -march=native -mcpu=neoverse-v2 since r14-10014-ga2f4be3dae04fa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114860 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org ---

[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630 --- Comment #5 from Nathaniel Shead --- I've been testing a patch series that tries to solve this from the other end (by remembering whether we were in the module purview when we deferred the instantiation and restoring that state within

[Bug tree-optimization/114864] [12/13/14/15 regression] wrong code at -O1 with "-fno-tree-dce -fno-tree-fre" on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114864 H.J. Lu changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #2

[Bug tree-optimization/114864] [12/13/14/15 regression] wrong code at -O1 with "-fno-tree-dce -fno-tree-fre" on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114864 Richard Biener changed: What|Removed |Added CC||jamborm at gcc dot gnu.org Ever

[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630 --- Comment #4 from Patrick Palka --- (In reply to Patrick Palka from comment #3) > And in 114630_c.C we no longer try to stream in the definition > of _M_do_parse() twice, for some reason. Oops, looks like we still stream in the definition

[Bug target/114860] [14/15 regression] [aarch64] 511.povray regresses by ~5.5% with -O3 -flto -march=native -mcpu=neoverse-v2 since r14-10014-ga2f4be3dae04fa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114860 --- Comment #1 from Tamar Christina --- Hmm I Am unable to reproduce this with -O3 - flto -mcpu=neoverse-v2 on a neoverse-v2 machine. Is any other option required? Also that code was new in gcc 14 and was partially reverted due to register

[Bug target/114861] [14/15 Regression] LoongArch: ICE building the kernel with -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0

[Bug target/114860] [14/15 regression] [aarch64] 511.povray regresses by ~5.5% with -O3 -flto -march=native -mcpu=neoverse-v2 since r14-10014-ga2f4be3dae04fa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114860 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0

[Bug c++/114856] [14/15 regression][modules] ICE (segfault)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114856 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0

[Bug middle-end/114855] ICE: Segfault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855 Richard Biener changed: What|Removed |Added CC||amacleod at redhat dot com Ever

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #10 from Jakub Jelinek --- (mode == HImode || mode == V16BImode) could be GET_MODE_SIZE (mode) == 2 too.

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #9 from Jakub Jelinek --- (In reply to Christophe Lyon from comment #7) > This fails because down the call chain from lowpart_subreg, we reach > gcc_unreachable in rtx_vector_builder::find_cached_value because m_mode == > V4BImode

[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm

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

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #8 from Christophe Lyon --- (In reply to Jakub Jelinek from comment #5) > Guess the primary question is why there is the gen_lowpart call at all. > Is it that normally the mode of x is already right due to the prototypes of > the

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #7 from Christophe Lyon --- (In reply to Jakub Jelinek from comment #4) > (In reply to Christophe Lyon from comment #3) > > lowpart_subreg does not work either. > > > > If we put the predicates in a variable in the testcase, then

[Bug target/114734] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl since r8-6047-g65dd1346027bb5

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #11 from Richard Biener --- posted the patch so the arm CI picks it up.

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #6 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #5) > So (completely untested): > --- gcc/config/arm/arm-mve-builtins.cc.jj 2024-03-19 09:51:05.203631194 > +0100 > +++ gcc/config/arm/arm-mve-builtins.cc

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #5 from Jakub Jelinek --- Guess the primary question is why there is the gen_lowpart call at all. Is it that normally the mode of x is already right due to the prototypes of the builtins, with the exception that gcc likes to promote

[Bug target/114734] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl since r8-6047-g65dd1346027bb5

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED

[Bug analyzer/111475] [14/15 regression] Many C++ analyzer tests FAIL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from David Malcolm --- > Sorry about this. > > Is there a machine in the compile farm I can test this on? Sure, both cfarm215 (Solaris/x86) and cfarm216

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #4 from Jakub Jelinek --- (In reply to Christophe Lyon from comment #3) > lowpart_subreg does not work either. > > If we put the predicates in a variable in the testcase, then in > function_expander::add_input_operand() x is

[Bug analyzer/111475] [14/15 regression] Many C++ analyzer tests FAIL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475 --- Comment #9 from David Malcolm --- Sorry about this. Is there a machine in the compile farm I can test this on?

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #3 from Christophe Lyon --- lowpart_subreg does not work either. If we put the predicates in a variable in the testcase, then in function_expander::add_input_operand() x is already a (subreg/s/v:HI (reg:SI 116 [ _3 ]) 0) so taking

[Bug analyzer/111475] [14/15 regression] Many C++ analyzer tests FAIL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475 Rainer Orth changed: What|Removed |Added CC||jakub at gcc dot gnu.org,

[Bug target/43644] __uint128_t missed optimizations.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43644 Roger Sayle changed: What|Removed |Added Resolution|--- |FIXED CC|

[Bug rtl-optimization/97756] [11/12/13 Regression] Inefficient handling of 128-bit arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97756 Roger Sayle changed: What|Removed |Added Known to work||14.0 Summary|[11/12/13/14/15

[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426 --- Comment #12 from Matt Thompson --- Jerry, Actually, I took a look at my reproducer and it's not quite what I was wanting (I made a mistake in the Jinja templates). I'm going to work on it now to fix this up. And I'll look at adding the

[Bug c++/114456] [C++26] P0609R3 - Attributes for structured bindings

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

[Bug libstdc++/114862] std::uppercase not applying to nan's and inf's

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114862 --- Comment #2 from Jonathan Wakely --- Libc++ has tests for "INF" (although only for long double, not float or double), so it's apparently not accidental. The relevant code is: if (floatfield == ios_base::fixed) { if (uppercase)

[Bug libstdc++/114863] std::format applying grouping to nan's and inf's

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863 --- Comment #2 from Jonathan Wakely --- Maybe we could also make _M_localize more efficient for finite values by not even attempting to use grouping for scientific format.

[Bug libstdc++/114863] std::format applying grouping to nan's and inf's

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863 --- Comment #1 from Jonathan Wakely --- --- a/libstdc++-v3/include/std/format +++ b/libstdc++-v3/include/std/format @@ -1734,7 +1734,7 @@ namespace __format } #endif - if (_M_spec._M_localized) + if

  1   2   >