[Bug target/114861] New: LoongArch: Fail to build the kernel with -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861 Bug ID: 114861 Summary: LoongArch: Fail to build the kernel with -Os Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tar

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861 --- Comment #1 from Xi Ruoyao --- Created attachment 58044 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58044&action=edit Preprocessed source

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102003 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:e207b67fcde224f2be0c79bf2a24f7fc75b6f481 commit r13-8651-ge207b67fcde224f2be0c79bf2a24f7fc75b6f481 Author: Andre Vehreschi

[Bug c++/114858] [11/12/13/14 regression] Compilation Hang and Excessive RAM Consumption in GCC with invalid input since r0-128725

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114858 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13/14 regression]|[11/12/13/14 regression]

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861 Xi Ruoyao changed: What|Removed |Added Priority|P3 |P2 --- Comment #2 from Xi Ruoyao --- It se

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

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

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114862 Bug ID: 114862 Summary: std::uppercase not applying to nan's and inf's Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

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

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

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863 Bug ID: 114863 Summary: std::format applying grouping to nan's and inf's Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Componen

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861 --- Comment #4 from Xi Ruoyao --- (In reply to Jakub Jelinek from comment #3) > m for register_operand??? Hmm indeed, the m alternative should be removed. I must had been sleeping when I typed it...

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 --- Comment #2 from Jakub Jelinek --- If it is Fortran FE, then the possible commits might be r14-9893 r14-9874 r14-9873 r14-9753 r14-9752 r14-9720 r14-9719 r14-9712 Anyway, best would be to try to compile the amg_d_jac_smoother_clone_settings.f

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 --- Comment #3 from Jakub Jelinek --- Oh, and start by disabling LTO and see if it makes a difference.

[Bug middle-end/111701] [11/12/13/14 Regression] wrong code for __builtin_signbit(x*x)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111701 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com --- Co

[Bug middle-end/113724] [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1 since r14-6515

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 --- Comment #10 from Jakub Jelinek

[Bug libgomp/113867] [14 Regression][OpenMP] Wrong code with mapping pointers in structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 --- Comment #6 from Jakub Jelinek -

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gc

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

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

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114862 --- Comment #1 from Jonathan Wakely --- Actually I think we're doing exactly what the standard requires: ios_base::fmtflags __fltfield = __flags & ios_base::floatfield; ... // [22.2.2.2.2] Table 58 if (__fltfield == ios_base::fi

[Bug target/110621] x86_64: Test gcc.target/i386/pr105354-2.c fails with -fstack-protector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110621 --- Comment #1 from GCC Commits --- The master branch has been updated by Haochen Jiang : https://gcc.gnu.org/g:4a2e55b3ada20fe6457466bb687a66c8d03e056e commit r14-10137-g4a2e55b3ada20fe6457466bb687a66c8d03e056e Author: Haochen Jiang Date:

[Bug target/110621] x86_64: Test gcc.target/i386/pr105354-2.c fails with -fstack-protector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110621 --- Comment #2 from GCC Commits --- The releases/gcc-13 branch has been updated by Haochen Jiang : https://gcc.gnu.org/g:7425436b5382a04f3eb28c7c7912f4d9a1cad0bd commit r13-8652-g7425436b5382a04f3eb28c7c7912f4d9a1cad0bd Author: Haochen Jiang

[Bug target/110621] x86_64: Test gcc.target/i386/pr105354-2.c fails with -fstack-protector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110621 Haochen Jiang changed: What|Removed |Added CC||haochen.jiang at intel dot com --- Comm

[Bug target/110621] x86_64: Test gcc.target/i386/pr105354-2.c fails with -fstack-protector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110621 Hongtao Liu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug tree-optimization/114864] New: wrong code at -O1 with "-fno-tree-dce -fno-tree-fre" on x86_64-linux-gnu

ecking=yes --prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.1 20240426 (experimental) (GCC) [589] % [589] % gcctk -O1 small.c; ./a.out [59

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861 Xi Ruoyao changed: What|Removed |Added Keywords|needs-reduction |ice-on-valid-code --- Comment #5 from Xi Ru

[Bug fortran/84868] [11/12/13/14 Regression] ICE in gfc_conv_descriptor_offset, at fortran/trans-array.c:208

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84868 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org

[Bug fortran/61527] [11/12/13/14 Regression] [OOP] class/extends, multiple generic assignment, accept invalid

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

[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 (_M_spec._M_loca

[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++/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 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 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 rando

[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 Re

[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 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/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 g

[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 #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 already

[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 (Solaris/SPAR

[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 Assignee|unassigned

[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/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/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 #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 in

[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 bui

[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 #3

[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 (s

[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 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 co

[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 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 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 --- 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 al

[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 twic

[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 co

[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 f

[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 reopen_

[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 --- Comme

[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 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 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 gnu.or

[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 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 Severi

[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 | 0.100

[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 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 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 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 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 Vehresch

[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&action=edit pr114859.tar.xz Testcase + one module. I was using ./f951 -quiet -I . amg_d_hierarchy_bld.f90 -m64 -march=x86-

[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 #7 from Jakub Jelinek --- Created attachment 58047 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58047&action=edit pr114859-1.tar.xz Another module. Unfortunately, the last module is too large for the 1M limit. It can be gra

[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 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 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 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 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 Da

[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 D

[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/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/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 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 23.1

[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 g

[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 go

[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++ A

[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 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 --- Com

[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

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." ...

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 thi

[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 t

[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 w

[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 be

[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 Severity:

[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++/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/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 Status|WAI

[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 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 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 fla

[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 Prior

  1   2   >