[Bug libstdc++/120147] [16 Regression] libstdc++-v3 build failure for mingw32 target: src/c++23/print.cc:102:49: error: invalid conversion from 'std::basic_filebuf::native_handle_type' {aka 'int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120147 --- Comment #4 from LIU Hao --- configure:5: checking whether _get_osfhandle is defined in configure:54468: /home/lh_mouse/GitHub/MINGW-packages/mingw-w64-gcc/src/build-MINGW32/./gcc/xgcc -shared-libgcc -B/home/lh_mouse/GitHub/MINGW-packages/mingw-w64-gcc/src/build-MINGW32/./gcc -nostdinc++ -L/home/lh_mouse/GitHub/MINGW-packages/mingw-w64-gcc/src/build-MINGW32/i686-w64-mingw32/libstdc++-v3/src -L/home/lh_mouse/GitHub/MINGW-packages/mingw-w64-gcc/src/build-MINGW32/i686-w64-mingw32/libstdc++-v3/src/.libs -L/home/lh_mouse/GitHub/MINGW-packages/mingw-w64-gcc/src/build-MINGW32/i686-w64-mingw32/libstdc++-v3/libsupc++/.libs -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include -B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/i686-w64-mingw32/sys-include-c -O0 -S -I/mingw32/include conftest.cpp >&5 configure:54468: $? = 0 configure: failed program was: | /* confdefs.h */
[Bug libstdc++/120147] [16 Regression] libstdc++-v3 build failure for mingw32 target: src/c++23/print.cc:102:49: error: invalid conversion from 'std::basic_filebuf::native_handle_type' {aka 'int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120147 --- Comment #7 from Jonathan Wakely --- Yup, just noticed that.
[Bug tree-optimization/120080] [16 regression] ICE when building llvm-20.1.3 (find_bit_tests, at tree-switch-conversion.cc:1799) since r16-347-g1381a5114788a2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120080 --- Comment #11 from Sam James --- (In reply to Filip Kastl from comment #10) > This should work as a trivial fix: Replace the crashing line with > > if (l == 0) > return clusters.copy(); > > I'll bootstrap and regtest this fix and then I'll push it. Thanks, that's what I had in mind, but I had the same question below so wasn't sure... > > I thought that switch lowering shouldn't run into empty switches (can't > recall what made me think that though). I'll look into why that happens.
[Bug libstdc++/120114] Format width is not correctly handled for chrono formatting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120114 --- Comment #1 from GCC Commits --- The master branch has been updated by Tomasz Kaminski : https://gcc.gnu.org/g:52f6ab55051ff43fd1b40ff06d9501043f8ba844 commit r16-438-g52f6ab55051ff43fd1b40ff06d9501043f8ba844 Author: Tomasz KamiÅski Date: Mon May 5 16:32:58 2025 +0200 libstdc++: Fix width computation for the chrono formatting [PR120114] Use `__unicode::_field_width` to compute the field width of the output when writting the formatted output for std::chrono::types. This applies both to characters copied from format string, and one produced by localized formatting. We also use _Str_sink::view() instead of get(), which avoids copying the content of the buffer to std::string in case of small output. PR libstdc++/120114 libstdc++-v3/ChangeLog: * include/bits/chrono_io.h (__formatter_chrono::_M_format): Use __field_width. * testsuite/std/time/format/pr120114.cc: New test. Reviewed-by: Jonathan Wakely Signed-off-by: Tomasz KamiÅski
[Bug tree-optimization/120135] Strange -Wuninitialized behavior with struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120135 --- Comment #8 from Andrew Pinski --- (In reply to Manuel López-Ibáñez from comment #7) > I cannot see the warning with x86-64 gcc 15.1 (or trunk or 14.1 or 12.1). > > Maybe ARM GCC is doing something different? But this should not be > target-specific. It is sra decisions which is causing the difference between X86_64 and arm.
[Bug tree-optimization/120156] [14 Regression] Segfault while compiling eigen test bdcsvd.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120156 Andrew Pinski changed: What|Removed |Added Version|14.3.1 |14.2.1 Target Milestone|--- |14.3 Keywords||alias, ice-on-valid-code
[Bug ipa/120044] [12/13/14/15/16 Regression] wrong code at -O1 and above with "-fno-early-inlining -fno-tree-fre -fno-tree-pre -fno-code-hoisting" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120044 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=69708 --- Comment #4 from Martin Jambor --- Mine.
[Bug tree-optimization/111276] rewrite_to_defined_overflow rewrites already defined code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111276 --- Comment #10 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:d884e9c5c746a41b069905f990fa72b9e550 commit r16-449-gd884e9c5c746a41b069905f990fa72b9e550 Author: Andrew Pinski Date: Thu Sep 26 23:25:17 2024 + gimple: Add gimple_with_undefined_signed_overflow and use it [PR111276] While looking into the ifcombine, I noticed that rewrite_to_defined_overflow was rewriting already defined code. In the previous attempt at fixing this, the review mentioned we should not be calling rewrite_to_defined_overflow in those cases. The places which called rewrite_to_defined_overflow didn't always check the lhs of the assignment. This fixes the problem by introducing a helper function which is to be used before calling rewrite_to_defined_overflow. Bootstrapped and tested on x86_64-linux-gnu. gcc/ChangeLog: PR tree-optimization/111276 * gimple-fold.cc (arith_code_with_undefined_signed_overflow): Make static. (gimple_with_undefined_signed_overflow): New function. * gimple-fold.h (arith_code_with_undefined_signed_overflow): Remove. (gimple_with_undefined_signed_overflow): Add declaration. * tree-if-conv.cc (if_convertible_gimple_assign_stmt_p): Use gimple_with_undefined_signed_overflow instead of manually checking lhs and the code of the stmt. (predicate_statements): Likewise. * tree-ssa-ifcombine.cc (ifcombine_rewrite_to_defined_overflow): Likewise. * tree-ssa-loop-im.cc (move_computations_worker): Likewise. * tree-ssa-reassoc.cc (update_range_test): Likewise. Reformat. * tree-scalar-evolution.cc (final_value_replacement_loop): Use gimple_with_undefined_signed_overflow instead of arith_code_with_undefined_signed_overflow. * tree-ssa-loop-split.cc (split_loop): Likewise. Signed-off-by: Andrew Pinski
[Bug tree-optimization/116938] move_stmt in phiopt should use rewrite_to_defined_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116938 Bug 116938 depends on bug 111276, which changed state. Bug 111276 Summary: rewrite_to_defined_overflow rewrites already defined code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111276 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/111276] rewrite_to_defined_overflow rewrites already defined code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111276 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |16.0 Resolution|--- |FIXED --- Comment #11 from Andrew Pinski --- Fixed.
[Bug target/120154] New: [16 Regression] uring RTL pass: vect_permconst ICE: in decompose, at rtl.h:2312 with -march=rv64gv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120154 Bug ID: 120154 Summary: [16 Regression] uring RTL pass: vect_permconst ICE: in decompose, at rtl.h:2312 with -march=rv64gv Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: riscv64-unknown-linux-gnu Created attachment 61352 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61352&action=edit reduced testcase Compiler output: $ riscv64-unknown-linux-gnu-gcc -O1 -march=rv64gv testcase.c during RTL pass: vect_permconst testcase.c: In function 'foo': testcase.c:16:1: internal compiler error: in decompose, at rtl.h:2312 16 | } | ^ 0x374aa81 internal_error(char const*, ...) /repo/gcc-trunk/gcc/diagnostic-global-context.cc:517 0x1135c6d fancy_abort(char const*, int, char const*) /repo/gcc-trunk/gcc/diagnostic.cc:1815 0x188075f wi::int_traits >::decompose(long*, unsigned int, std::pair const&) /repo/gcc-trunk/gcc/rtl.h:2312 0x188075f wide_int_ref_storage::wide_int_ref_storage >(std::pair const&) /repo/gcc-trunk/gcc/wide-int.h:1089 0x188075f generic_wide_int >::generic_wide_int >(std::pair const&) /repo/gcc-trunk/gcc/wide-int.h:847 0x188075f poly_int<2u, generic_wide_int > >::poly_int>(poly_int_hungry, std::pair const&) /repo/gcc-trunk/gcc/poly-int.h:464 0x188075f poly_int<2u, generic_wide_int > >::poly_int >(std::pair const&) /repo/gcc-trunk/gcc/poly-int.h:457 0x188075f wi::to_poly_wide(rtx_def const*, machine_mode) /repo/gcc-trunk/gcc/rtl.h:2397 0x187fb8d rtx_vector_builder::step(rtx_def*, rtx_def*) const /repo/gcc-trunk/gcc/rtx-vector-builder.h:122 0x1880ae7 vector_builder::stepped_sequence_p(unsigned int, unsigned int, unsigned int) /repo/gcc-trunk/gcc/vector-builder.h:441 0x1880d0a vector_builder::try_npatterns(unsigned int) /repo/gcc-trunk/gcc/vector-builder.h:494 0x1880f46 vector_builder::finalize() /repo/gcc-trunk/gcc/vector-builder.h:582 0x188047e rtx_vector_builder::build(rtvec_def*) /repo/gcc-trunk/gcc/rtx-vector-builder.cc:33 0x142b62f gen_rtx_CONST_VECTOR(machine_mode, rtvec_def*) /repo/gcc-trunk/gcc/emit-rtl.cc:6224 0x1e3ede2 vector_permconst::process_bb(basic_block_def*) /repo/gcc-trunk/gcc/config/riscv/riscv-vect-permconst.cc:217 0x1e3f16a vector_permconst::execute(function*) /repo/gcc-trunk/gcc/config/riscv/riscv-vect-permconst.cc:291 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ riscv64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20250506192155-r16-433-g2c46a74d4707bd-checking-yes-rtl-df-extra-nobootstrap-nographite-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/16.0.0/lto-wrapper Target: riscv64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --without-cloog --without-ppl --without-isl --with-isa-spec=2.2 --with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu --with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld --with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib --enable-libsanitizer --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-20250506192155-r16-433-g2c46a74d4707bd-checking-yes-rtl-df-extra-nobootstrap-nographite-riscv64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 16.0.0 20250507 (experimental) (GCC)
[Bug target/120154] [16 Regression] uring RTL pass: vect_permconst ICE: in decompose, at rtl.h:2312 with -march=rv64gv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120154 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jeffrey A. Law --- Same root cause. Should be easy to fix. *** This bug has been marked as a duplicate of bug 120137 ***
[Bug target/120157] No use of SVE early break vectorisation in FP loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120157
--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to Tamar Christina from comment #1)
> (In reply to ktkachov from comment #0)
> > Not sure if this is a target-specific issue or not. For input:
> > int f11(float *x, float val, int n)
> > {
> > int i;
> > for (i = 0; i < n; i++) {
> > if (x[i] == val) break;
> > }
> > return i;
> > }
> >
> > GCC can do early-break vectorisation with e.g. -Ofast -mcpu=grace but it
> > always uses a Neon sequence, even if we use a more aggressive SVE core like
> > -mcpu=a64fx. It refuses to do it even with --param
> > aarch64-autovec-preference=sve-only.
> >
> > Is there some enablement we're missing?
>
> The loop requires first faulting loads to vectorize with SVE which we don't
> support yet. In theory peeling for alignment for SVE could work as well but
> there are limitations in which cases we can use it and since the max VL is
> 2048 a single loop iteration can easily load more than a page worth of data.
>
> So for GCC 15 only *fixed length* SVE can vectorize and for GCC 16 we're
> working on VLA.
>
> e.g. https://godbolt.org/z/dYc6szWqa
Ah indeed, -msve-vector-bits= does do what I expected. Feel free to close this
if it's not tracking anything new then.
[Bug libfortran/120158] New: Incorrect UNSIGNED maxval/maxloc etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120158
Bug ID: 120158
Summary: Incorrect UNSIGNED maxval/maxloc etc.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
maxval/maxloc use
#if defined('atype_inf`)
maxval = -atype_inf;
#else
maxval = atype_min;
#endif',
compared to minval/minloc
#if defined('atype_inf`)
minval = atype_inf;
#else
minval = atype_max;
#endif',
Both of that is reasonable, but I think the atype_min definition for UNSIGNED
is incorrect.
The
../../../libgfortran/generated/maxloc0_8_m1.c:274:14: warning: unsigned
conversion from ‘int’ to ‘GFC_UINTEGER_1’ {aka ‘unsigned char’} changes value
from ‘-255’ to ‘1’ [-Woverflow]
../../../libgfortran/generated/maxloc0_4_m2.c:99:14: warning: unsigned
conversion from ‘int’ to ‘GFC_UINTEGER_2’ {aka ‘short unsigned int’} changes
value from ‘-65535’ to ‘1’ [-Woverflow]
etc. warnings are suspicious.
At least in C, minimum for unsigned is 0 and maximum 0x while signed
int have
minimum of -0x7fff - 1 and maximum 0x7fff. In Fortran for INTEGER I
believe maximum is 0x7fff and minimum -0x7fff, but it would really
surprise me if UNSIGNED maximum wasn't 0x and minimum 0.
So, I think we need to somehow arrange for atype_min to be ((GFC_UINTEGER_N) 0)
or so
(for N 1, 2, 4, 8 or 16), or predefine macros for it in libgfortran and just
arrange for
define(atype_min,ifelse(regexp(file,
`_\(.\)[0-9]*\.c$',`\1'),`i',`(-'atype_max`-1)',`-'atype_max))dnl
to be perhaps
--- libgfortran/m4/iparm.m4.jj 2024-09-25 17:25:07.201360961 +0200
+++ libgfortran/m4/iparm.m4 2025-05-07 15:53:42.940954331 +0200
@@ -28,7 +28,7 @@ define_type(rtype, rtype_tmp)dnl
define(rtype_qual,`_'rtype_kind)dnl
')dnl
define(atype_max, atype_name`_HUGE')dnl
-define(atype_min,ifelse(regexp(file, `_\(.\)[0-9]*\.c$',
`\1'),`i',`(-'atype_max`-1)',`-'atype_max))dnl
+define(atype_min,ifelse(index(atype_name,`UNSIGNED`),-1,ifelse(regexp(file,
`_\(.\)[0-9]*\.c$', `\1'),`i',`(-'atype_max`-1)',`-'atype_max),`((`atype_name`)
0)`))dnl
define(atype_inf, atype_name`_INFINITY')dnl
define(atype_nan, atype_name`_QUIET_NAN')dnl
define(name, regexp(regexp(file, `[^/]*$', `\&'), `^\([^_]*\)_', `\1'))dnl
? So far completely untested.
[Bug target/120157] No use of SVE early break vectorisation in FP loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120157 Tamar Christina changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org Blocks||53947, 115130 Ever confirmed|0 |1 Last reconfirmed||2025-05-07 --- Comment #3 from Tamar Christina --- I don't think we have an upstream ticket for this issue so I'll leave it and assign it to Alex who's working on this. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115130 [Bug 115130] [meta-bug] early break vectorization
[Bug target/120157] No use of SVE early break vectorisation in FP loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120157
--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #2)
> (In reply to Tamar Christina from comment #1)
> > (In reply to ktkachov from comment #0)
> > > Not sure if this is a target-specific issue or not. For input:
> > > int f11(float *x, float val, int n)
> > > {
> > > int i;
> > > for (i = 0; i < n; i++) {
> > > if (x[i] == val) break;
> > > }
> > > return i;
> > > }
> > >
> > > GCC can do early-break vectorisation with e.g. -Ofast -mcpu=grace but it
> > > always uses a Neon sequence, even if we use a more aggressive SVE core
> > > like
> > > -mcpu=a64fx. It refuses to do it even with --param
> > > aarch64-autovec-preference=sve-only.
> > >
> > > Is there some enablement we're missing?
> >
> > The loop requires first faulting loads to vectorize with SVE which we don't
> > support yet. In theory peeling for alignment for SVE could work as well but
> > there are limitations in which cases we can use it and since the max VL is
> > 2048 a single loop iteration can easily load more than a page worth of data.
> >
> > So for GCC 15 only *fixed length* SVE can vectorize and for GCC 16 we're
> > working on VLA.
> >
> > e.g. https://godbolt.org/z/dYc6szWqa
>
> Ah indeed, -msve-vector-bits= does do what I expected. Feel free to close
> this if it's not tracking anything new then.
Ok. FWIW the original testcase for me had doubles:
int f11(double *x, double val, int n)
{
int i;
for (i = 0; i < n; i++) {
if (x[i] == val) break;
}
return i;
}
And with -msve-vector-bits=128 -mcpu=neoverse-v2 --param
aarch64-autovec-preference=sve-only GCC refuses to vectorise and picks Neon
without the aarch64-autovec-preference. I do see it vectorising with VLS SVE
for wider widths, so it may be a V2 cost model thing.
If choosing Neon is the right thing to do for V2 that's fine, but with --param
aarch64-autovec-preference=sve-only it should probably use SVE rather than
refusing to vectorise
[Bug ipa/119852] The output of -fdump-ipa-clones can contain "(null)" as the suffix/reason for cloning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119852 --- Comment #5 from GCC Commits --- The releases/gcc-15 branch has been updated by Martin Jambor : https://gcc.gnu.org/g:77780c31485eeb71e9fabf8ea9d4b1af0c3be595 commit r15-9633-g77780c31485eeb71e9fabf8ea9d4b1af0c3be595 Author: Martin Jambor Date: Tue May 6 17:28:43 2025 +0200 ipa: Do not emit info about temporary clones to ipa-clones dump (PR119852) As described in PR 119852, the output of -fdump-ipa-clones can contain "(null)" as the suffix/reason for cloning when we need to create a clone to hold the original function during recursive inlining. Such clone is never output and so should not be part of the dump output either. gcc/ChangeLog: 2025-04-23 Martin Jambor PR ipa/119852 * cgraphclones.cc (dump_callgraph_transformation): Document the function. Do not dump if suffix is NULL. gcc/testsuite/ChangeLog: 2025-04-23 Martin Jambor PR ipa/119852 * gcc.dg/ipa/pr119852.c: New test. (cherry picked from commit fb5829a01651d427a63a12c44ecc8baa47dbfc83)
[Bug target/120157] No use of SVE early break vectorisation in FP loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120157
--- Comment #5 from Tamar Christina ---
(In reply to ktkachov from comment #4)
> > Ah indeed, -msve-vector-bits= does do what I expected. Feel free to close
> > this if it's not tracking anything new then.
>
> Ok. FWIW the original testcase for me had doubles:
> int f11(double *x, double val, int n)
> {
> int i;
> for (i = 0; i < n; i++) {
> if (x[i] == val) break;
> }
> return i;
> }
>
> And with -msve-vector-bits=128 -mcpu=neoverse-v2 --param
> aarch64-autovec-preference=sve-only GCC refuses to vectorise and picks Neon
> without the aarch64-autovec-preference. I do see it vectorising with VLS SVE
> for wider widths, so it may be a V2 cost model thing.
> If choosing Neon is the right thing to do for V2 that's fine, but with
> --param aarch64-autovec-preference=sve-only it should probably use SVE
> rather than refusing to vectorise
Yeah I don't really know why it did that. Will need to have a look to see how
sve-only is implemented.
It looks like analysis did succeed for at least one SVE mode but it's correct
in that SVE would be more expensive here
/app/example.c:7:19: note:Runtime profitability threshold = 1
/app/example.c:7:19: note:Static estimate profitability threshold = 12
/app/example.c:7:19: note: * Analysis succeeded with vector mode VNx2QI
/app/example.c:7:19: note: Comparing two main loops (VNx2QI at VF 2 vs V2DF at
VF 4)
/app/example.c:7:19: note: * Choosing vector mode V2DF
SVE is more expensive due to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119860
If you change your counter from `int` to `long` to match the load type
https://godbolt.org/z/dYc49ojM9 you get the code you expected.
This is a general vectorizer quirk that we'll hopefully address this release
too *knocks on wood* ...but haven't taken a look at Richard's old WIP patches
yet.
[Bug fortran/120131] Misleading and unnecessary error message due to range check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120131 --- Comment #9 from kargls at comcast dot net --- (In reply to Vladimir Terzi from comment #8) > I initially changed the status, because I assumed that my questions in > comment #2 will be ignored. > > (In reply to kargls from comment #6) > > I suppose it is somewhat naive of gfortran contributors to expect that users > > read the documentation supplied with the compiler. > > Not in the case of what is assumed to be common knowledge. Most of Stack > Overflow users claimed that the correct integer*4 range in Fortran is > [-2147483648:2147483647]. This statement can even be found in Fortran > language references of Oracle and IBM. > > (In reply to kargls from comment #6) > > ‘-fno-range-check’ > > Disable range checking on results of simplification of constant > > expressions during compilation. For example, GNU Fortran gives an > > error at compile time when simplifying ‘a = 1. / 0’. With this > > option, no error is given and ‘a’ is assigned the value > > ‘+Infinity’. If an expression evaluates to a value outside of the > > relevant range of [‘-HUGE()’:‘HUGE()’], then the expression is > > replaced by ‘-Inf’ or ‘+Inf’ as appropriate. Similarly, ‘DATA > > i/Z''/’ results in an integer overflow on most systems, but > > with ‘-fno-range-check’ the value "wraps around" and ‘i’ is > > initialized to -1 instead. > > > > Those last two sentences are important. > > I fail to see, how this two sentences explain that z'8000' is an invalid > integer of kind 4 due to the Fortran standard. > > (In reply to kargls from comment #6) > > % gfortran14 -o z -fno-range-check -pedantic a.f90 && ./z > > a.f90:1:21: > > > > 1 | print *, -2147483648 > > | 1 > > Warning: Integer outside symmetric range implied by Standard Fortran at (1) > > -2147483648 > > > > So, yes, more than one gfortran contributor has thought about the corner > > case of -huge(1) - 1. > > This is the message I would have wished to see as the error message in this > case. GCC bugzilla is not the place to learn Fortran. F2023, 6.2.3 Constants R605 literal-constant is int-literal-constant or real-literal-constant or complex-literal-constant or logical-literal-constant or char-literal-constant or boz-literal-constant F2023, 7.4.3.1 Integer type Any integer value can be represented as a signed-int-literal-constant. R707 signed-int-literal-constant is [ sign ] int-literal-constant R708 int-literal-constantis digit-string [ _kind-param ] R709 kind-param is digit-string or scalar-int-constant-name R710 signed-digit-string is [ sign ] digit-string R711 digit-stringis digit [ digit ] ... R712 signis + or 'K = -2147483648' is an expression via R605 and R708. F2023, 10.1.2.2 Primary R1001 primary 10.1.2.2 Primary is literal-constant or ... We have already established 'K = -2147483648' is an expression. F2023, 10.1.2.4 Level-1 expressions R1003 level-1-expr is [ defined-unary-op ] primary R1004 defined-unary-op is .letter [ letter ] ... . F2023, 10.1.2.5 Level-2 expressions R1005 mult-operand is level-1-expr [ power-op mult-operand ] R1006 add-operand is [ add-operand mult-op ] mult-operand R1007 level-2-expr is [ [ level-2-expr ] add-op ] add-operand ... R1010 add-opis + or ... Note Simple examples of a level-2 expression are: Example Syntactic class Remarks ... ... ... +1 level-2-expr + is an add-op and 1 is an add-operand. (R1007) You can replace the '+' add-op with the '-' add-op in the above note. (And, yes, I know a Note in the Fortran standard is non-normative text.) This should be sufficient in understanding why gfortran issues an error without the -fno-range-check option. Other compiler that silently accept 'K = -2147483648' are simply appeasing their users. Now, you're going to complain that gfortran accepts 'K = - HUGE(1) - 1'. F2023, 10.1.5.2.4 Evaluation of numeric intrinsic operations The execution of any numeric operation whose result is not defined by the arithmetic used by the processor is prohibited. You are hitting processor-dependent behavior. The arithmetic for INTEGER on your system has the range [-HUGE(1)-1, HUGE(1)]. But, wait a minute, what about the model number representation of an INTEGER from F2023, 16.4? This seems to imply that an INTEGER is symmetric (and hence the -pedantic warning which I have considered for removal). The model numbers apply to the intrinsic subprograms, and the Fortran s
[Bug fortran/120163] [15/16 Regression] Can not import module containig call to pure routine via abstract interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120163 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Keywords||rejects-valid Last reconfirmed||2025-05-07 Status|UNCONFIRMED |NEW CC||tkoenig at gcc dot gnu.org Known to fail||15.1.1, 16.0 Known to work||14.2.1 Summary|Can not import module |[15/16 Regression] Can not |containig call to pure |import module containig |routine via abstract|call to pure routine via |interface |abstract interface --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Workaround: use -Wno-external-argument-mismatch to disable the new check. @Thomas: can you have a look?
[Bug libgomp/120167] [16 Regression] FAIL: libgomp.graphite/force-parallel-1.c by r16-372-g064cac730f88dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120167 H.J. Lu changed: What|Removed |Added Summary|[16 Regression] FAIL: |[16 Regression] FAIL: |libgomp.graphite/force-para |libgomp.graphite/force-para |llel-1.c|llel-1.c by ||r16-372-g064cac730f88dc Last reconfirmed||2025-05-08 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||hubicka at ucw dot cz --- Comment #1 from H.J. Lu --- It is caused by r16-372-g064cac730f88dc.
[Bug libgomp/120167] New: [16 Regression] FAIL: libgomp.graphite/force-parallel-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120167 Bug ID: 120167 Summary: [16 Regression] FAIL: libgomp.graphite/force-parallel-1.c Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: jakub at gcc dot gnu.org Target Milestone: --- On x86-64, I got FAIL: libgomp.graphite/force-parallel-1.c scan-tree-dump-times graphite "2 loops carried no dependency" 1 FAIL: libgomp.graphite/force-parallel-1.c scan-tree-dump-times optimized "loopfn" 8
[Bug c++/120127] ICE in GCC when calling destructor of undefined type name in lambda (lookup_template_class crash)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120127 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #1 from mcccs at gmx dot com --- bisection bad commit: r12-3643-g18b57c1d4a8777
[Bug fortran/120131] Misleading and unnecessary error message due to range check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120131 --- Comment #8 from Vladimir Terzi --- I initially changed the status, because I assumed that my questions in comment #2 will be ignored. (In reply to kargls from comment #6) > I suppose it is somewhat naive of gfortran contributors to expect that users > read the documentation supplied with the compiler. Not in the case of what is assumed to be common knowledge. Most of Stack Overflow users claimed that the correct integer*4 range in Fortran is [-2147483648:2147483647]. This statement can even be found in Fortran language references of Oracle and IBM. (In reply to kargls from comment #6) > ‘-fno-range-check’ > Disable range checking on results of simplification of constant > expressions during compilation. For example, GNU Fortran gives an > error at compile time when simplifying ‘a = 1. / 0’. With this > option, no error is given and ‘a’ is assigned the value > ‘+Infinity’. If an expression evaluates to a value outside of the > relevant range of [‘-HUGE()’:‘HUGE()’], then the expression is > replaced by ‘-Inf’ or ‘+Inf’ as appropriate. Similarly, ‘DATA > i/Z''/’ results in an integer overflow on most systems, but > with ‘-fno-range-check’ the value "wraps around" and ‘i’ is > initialized to -1 instead. > > Those last two sentences are important. I fail to see, how this two sentences explain that z'8000' is an invalid integer of kind 4 due to the Fortran standard. (In reply to kargls from comment #6) > % gfortran14 -o z -fno-range-check -pedantic a.f90 && ./z > a.f90:1:21: > > 1 | print *, -2147483648 > | 1 > Warning: Integer outside symmetric range implied by Standard Fortran at (1) > -2147483648 > > So, yes, more than one gfortran contributor has thought about the corner > case of -huge(1) - 1. This is the message I would have wished to see as the error message in this case.
[Bug libstdc++/120147] [16 Regression] libstdc++-v3 build failure for mingw32 target: src/c++23/print.cc:102:49: error: invalid conversion from 'std::basic_filebuf::native_handle_type' {aka 'int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120147
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:83ef989ee189902ca1d434feb0f3dd50519e92cb
commit r16-437-g83ef989ee189902ca1d434feb0f3dd50519e92cb
Author: Jonathan Wakely
Date: Wed May 7 10:44:49 2025 +0100
libstdc++: Remove use of undefined GLIBCXX_LANG_{PUSH,POP} [PR120147]
Commit r16-427-g86627faec10da5 was using the new GLIBCXX_LANG_PUSH and
GLIBCXX_LANG_POP macros from a change that I haven't pushed yet,
resulting in changes to CXXFLAGS not being restored after the
GLIBCXX_ENABLE_BACKTRACE checks.
libstdc++-v3/ChangeLog:
PR libstdc++/120147
* acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Restore use of
AC_LANG_CPLUSPLUS.
* configure: Regenerate.
[Bug libstdc++/120147] [16 Regression] libstdc++-v3 build failure for mingw32 target: src/c++23/print.cc:102:49: error: invalid conversion from 'std::basic_filebuf::native_handle_type' {aka 'int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120147 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jonathan Wakely --- Fixed, thanks for the report.
[Bug fortran/106065] Crash when reading extended derived type array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106065 philippe.wautelet at cnrs dot fr changed: What|Removed |Added Version|13.2.0 |15.1.0 --- Comment #4 from philippe.wautelet at cnrs dot fr --- Hello, This bug is opened for nearly 3 years and no update? Regards,
[Bug target/97786] rs6000 isinf etc. are pretty horrible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97786
--- Comment #4 from Surya Kumari Jangala ---
For the following test:
int test1 (double x)
{
return __builtin_isinf_sign (x);
}
The assembly generated by trunk is:
xststdcdp 0,1,48
mfcr 3,128
rlwinm 3,3,3,1
bne 0,.L2
mfvsrd 10,1
li 3,1
li 9,-1
cmpdi 0,10,0
isel 3,9,3,0
.L2:
extsw 3,3
blr
However, the sign of 'x' is stored in the CR register at bit 32. So the code
for the builtin can be optimized as follows:
xststdcdp 0,1,48
mfcr 4,128
rlwinm 3,4,3,1
bne 0,.L2
li 9,-1
isel 3,9,3,0//r3 already contains 1 due to 'rlwinm'
.L2:
extsw 3,3
blr
[Bug target/120157] New: No use of SVE early break vectorisation in FP loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120157
Bug ID: 120157
Summary: No use of SVE early break vectorisation in FP loop
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: aarch64-sve, missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
CC: tnfchris at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Not sure if this is a target-specific issue or not. For input:
int f11(float *x, float val, int n)
{
int i;
for (i = 0; i < n; i++) {
if (x[i] == val) break;
}
return i;
}
GCC can do early-break vectorisation with e.g. -Ofast -mcpu=grace but it always
uses a Neon sequence, even if we use a more aggressive SVE core like
-mcpu=a64fx. It refuses to do it even with --param
aarch64-autovec-preference=sve-only.
Is there some enablement we're missing?
[Bug target/120157] No use of SVE early break vectorisation in FP loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120157
--- Comment #1 from Tamar Christina ---
(In reply to ktkachov from comment #0)
> Not sure if this is a target-specific issue or not. For input:
> int f11(float *x, float val, int n)
> {
> int i;
> for (i = 0; i < n; i++) {
> if (x[i] == val) break;
> }
> return i;
> }
>
> GCC can do early-break vectorisation with e.g. -Ofast -mcpu=grace but it
> always uses a Neon sequence, even if we use a more aggressive SVE core like
> -mcpu=a64fx. It refuses to do it even with --param
> aarch64-autovec-preference=sve-only.
>
> Is there some enablement we're missing?
The loop requires first faulting loads to vectorize with SVE which we don't
support yet. In theory peeling for alignment for SVE could work as well but
there are limitations in which cases we can use it and since the max VL is 2048
a single loop iteration can easily load more than a page worth of data.
So for GCC 15 only *fixed length* SVE can vectorize and for GCC 16 we're
working on VLA.
e.g. https://godbolt.org/z/dYc6szWqa
[Bug c++/120155] New: ICE when lambda return type is the decltype of statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120155
Bug ID: 120155
Summary: ICE when lambda return type is the decltype of
statement expression
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: winmikedows at hotmail dot com
Target Milestone: ---
```cpp
void fun()
{
[](auto t) -> decltype(
({
int a = t;
})
) {};
}
```
ICEs all the way from GCC 11.1 to trunk. Interestingly, in published versions
(11.1 to 15.1) the error message is
```
: In function 'void fun()':
:5:21: internal compiler error: in dependent_type_p, at cp/pt.c:26813
5 | int a = t;
| ^
0x1780bf9 internal_error(char const*, ...)
???:0
0x677e40 fancy_abort(char const*, int, char const*)
???:0
0x7cc37c dependent_type_p(tree_node*)
???:0
0x6b50e5 is_rvalue_constant_expression(tree_node*)
???:0
0x7c0cab c_parse_file()
???:0
0x892aa2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/120088] Use of uninitialized value in constant expression when copy-constructing a std::expected from another copy-assigned non-erroneous std::expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120088
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #2 from Jiang An ---
I think GCC and MSVC are right here and libstdc++ is also fine.
The divergence is probably due to that Clang and EDG haven't implemented
CWG2658
(https://cplusplus.github.io/CWG/issues/2658.html).
A more reduced example:
```
struct expected_like {
union {
struct { } m_dummy {};
int m_unex;
};
};
constexpr bool quux() {
using I = int;
expected_like foo1{.m_unex{}};
foo1.m_unex.~I();
[[maybe_unused]] expected_like foo3{foo1};
return true;
}
static_assert(quux());
```
https://godbolt.org/z/Y64M4YMPP
[Bug libfortran/120153] New: Missing UINTEGER symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120153 Bug ID: 120153 Summary: Missing UINTEGER symbols Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- Looking at the GFORTRAN_15 symbols, I miss 4 symbols. In particular _gfortran_arandom_m16 _gfortran_maxloc1_16_m16 _gfortran_mmaxloc1_16_m16 _gfortran_smaxloc1_16_m16 The first one is caused by a typo, libgfortran/intrinsics/random.c has #ifdef GFC_HAVE_GFC_UINTEGER_16 rather than expected #ifdef HAVE_GFC_UINTEGER_16 around it. The rest because libgfortran/generated/maxloc1_16_m16.c file is missing (i_maxloc1_c doesn't have generated/maxloc1_16_m16.c \ entry). Now, because GCC 15.1 has been released, I think we need to export those at GFORTRAN_15.2 instead of GFORTRAN_15.
[Bug target/113939] Switch m68k to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113939 --- Comment #9 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #8) > (In reply to John Paul Adrian Glaubitz from comment #7) > > I will verify now that the M2 issue is related to enabling LRA. > > The M2 issue is indeed related to LRA. Will test Fortran now. Aha, updating my local repository to 8a8cd146cfd fixed the Fortran problem. Let me retest M2 with this git revision.
[Bug target/113939] Switch m68k to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113939 --- Comment #10 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #9) > (In reply to John Paul Adrian Glaubitz from comment #8) > > (In reply to John Paul Adrian Glaubitz from comment #7) > > > I will verify now that the M2 issue is related to enabling LRA. > > > > The M2 issue is indeed related to LRA. Will test Fortran now. > > Aha, updating my local repository to 8a8cd146cfd fixed the Fortran problem. Scratch that, I accidentally disabled the bootstrap again. *sigh*
[Bug c++/66279] [12/13 Regression] Input/output asm operand is not loaded inside a constructor with a virtual base class since r0-116348-g660584689a4397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66279 --- Comment #11 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:a145eaf1128ef4392cf6e624f4b23648cbe645eb commit r13-9636-ga145eaf1128ef4392cf6e624f4b23648cbe645eb Author: Richard Biener Date: Fri Feb 28 09:58:36 2025 +0100 middle-end/66279 - gimplification clobbers shared asm constraints When the C++ frontend clones a CTOR we do not copy ASM_EXPR constraints fully as walk_tree does not recurse to TREE_PURPOSE of TREE_LIST nodes. At this point doing that seems too dangerous so the following instead avoids gimplification of ASM_EXPRs to clobber the shared constraints and unshares it there, like it also unshares TREE_VALUE when it re-writes a "+" output constraint to separate "=" output and matching input constraint. PR middle-end/66279 * gimplify.cc (gimplify_asm_expr): Copy TREE_PURPOSE before rewriting it for "+" processing. * g++.dg/pr66279.C: New testcase. (cherry picked from commit 95f5d6cc17e7d6b689674756c62b6b5e1284afd0)
[Bug c/61579] -Wwrite-strings does not behave as a warning option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61579 --- Comment #11 from Jonathan Wakely --- One consequence of it not being a warning option is that -Werror=write-strings is accepted but behaves identically to -Wwrite-strings, which is pretty surprising. You need to use -Wwrite-strings -Werror=discarded-qualifiers to really enforce string literals as const types (which would make a lot more sense if it was -fwrite-strings).
[Bug tree-optimization/118950] [14 regression] RISC-V: rv64gcv runtime mismatch at -O3 since r14-4038-gb975c0dc3be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950 --- Comment #14 from GCC Commits --- The releases/gcc-14 branch has been updated by Robin Dapp : https://gcc.gnu.org/g:bed0053a28e238cb9c079a3ec89341541390f933 commit r14-11747-gbed0053a28e238cb9c079a3ec89341541390f933 Author: Robin Dapp Date: Fri Feb 21 07:19:40 2025 +0100 vect: Use original LHS type for gather pattern [PR118950]. In PR118950 we do not zero masked elements in a gather load. While recognizing a gather/scatter pattern we do not use the original type of the LHS. This matters because the type can differ with bool patterns (e.g. _Bool vs unsigned char) and we don't notice the need for zeroing out the padding bytes. This patch just uses the original LHS's type. PR middle-end/118950 gcc/ChangeLog: * tree-vect-patterns.cc (vect_recog_gather_scatter_pattern): Use original LHS's type. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/pr118950.c: New test. (cherry picked from commit f3d4208e798afafcba5246334004e9646e390681)
[Bug c/120162] Prefetch causes vectorization to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120162 --- Comment #2 from Viktor Horsmanheimo --- Created attachment 61355 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61355&action=edit PoC in C
[Bug c++/120161] Deduction failure with nested dependent type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120161 --- Comment #1 from Andrew Pinski --- Created attachment 61356 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61356&action=edit reducing The templated type alias is not part of the problem so remove it.
[Bug c++/120161] New: Deduction failure with nested dependent type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120161
Bug ID: 120161
Summary: Deduction failure with nested dependent type
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Consider this program, which is a reduction of attempting to use Boost.Mp11's
mp_map_find:
template struct mp_list { };
template
struct Wrap {
struct type { };
};
#if 0
template using C = T; // works
#else
template using C = typename Wrap::type; // fails
#endif
struct U : mp_list, void>
, mp_list, void>
{ };
template static auto f(mp_list, U...>*) -> int;
static auto f(...) -> char;
static_assert(__is_same(decltype(f(static_cast(nullptr))), int));
When C is just defined as T (flip the preprocessor), this check works. When
C is defined as Wrap::type, it fails on gcc 14 and gcc 15 (although it
pass on gcc 13, gcc 12, etc.). It passes on clang either way.
I don't think the particular spelling of C should matter here (as long as
C and C are distinct types).
[Bug c/120162] New: Prefetch causes vectorization to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120162 Bug ID: 120162 Summary: Prefetch causes vectorization to fail Product: gcc Version: 15.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: viktor.horsmanheimo at gmail dot com Target Milestone: --- Hi, It seems that prefetching causes vectorization to fail in some cases, I spoke on the dev IRC where using the builtin method was suggested, this also fails to vectorize the code properly. This behavior seems to be consistent with any GCC version I've tried (including older ones, 14.1 that I have on my computer) Incidentally this behavior can be seen on other major compiler vendors (Clang, MSVC) as well (if this is relevant). Command line: gcc -O3 -march=skylake Compiler output: N/a Preprocessed file: attached I've created a small PoC where this can be seen here: C++: https://godbolt.org/z/961hGaGvG. C: https://godbolt.org/z/Th5n3MceW Compiler information from godbolt: COLLECT_GCC=/opt/compiler-explorer/gcc-15.1.0/bin/gcc Target: x86_64-linux-gnu Configured with: ../gcc-15.1.0/configure --prefix=/opt/compiler-explorer/gcc-build/staging --enable-libstdcxx-backtrace=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap --enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada,objc,obj-c++,go,d,m2,rust,cobol --enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix --with-pkgversion=Compiler-Explorer-Build-gcc--binutils-2.42 Thread model: posix Supported LTO compression algorithms: zlib gcc version 15.1.0 (Compiler-Explorer-Build-gcc--binutils-2.42) COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s' '-masm=intel' '-fno-verbose-asm' '-S' '-O3' '-march=skylake' '-v' '-dumpdir' '/app/' /opt/compiler-explorer/gcc-15.1.0/bin/../libexec/gcc/x86_64-linux-gnu/15.1.0/cc1 -quiet -v -imultiarch x86_64-linux-gnu -iprefix /opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/x86_64-linux-gnu/15.1.0/ -quiet -dumpdir /app/ -dumpbase output.c -dumpbase-ext .c -masm=intel -march=skylake -g -O3 -version -fdiagnostics-color=always -fno-verbose-asm -o /app/output.s GNU C23 (Compiler-Explorer-Build-gcc--binutils-2.42) version 15.1.0 (x86_64-linux-gnu) compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/x86_64-linux-gnu/15.1.0/../../../../x86_64-linux-gnu/include" ignoring duplicate directory "/opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.1.0/include" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.1.0/include-fixed/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.1.0/include-fixed" ignoring nonexistent directory "/opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.1.0/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/x86_64-linux-gnu/15.1.0/include /opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/x86_64-linux-gnu/15.1.0/include-fixed/x86_64-linux-gnu /opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/x86_64-linux-gnu/15.1.0/include-fixed /usr/local/include /opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/../../include /usr/include/x86_64-linux-gnu /usr/include End of search list. Compiler executable checksum: 8cc01216ec82be553d57fcd4d8cd204d COMPILER_PATH=/opt/compiler-explorer/gcc-15.1.0/bin/../libexec/gcc/x86_64-linux-gnu/15.1.0/:/opt/compiler-explorer/gcc-15.1.0/bin/../libexec/gcc/x86_64-linux-gnu/:/opt/compiler-explorer/gcc-15.1.0/bin/../libexec/gcc/:/opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/x86_64-linux-gnu/15.1.0/../../../../x86_64-linux-gnu/bin/ LIBRARY_PATH=/opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/x86_64-linux-gnu/15.1.0/:/opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/x86_64-linux-gnu/:/opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/:/opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/x86_64-linux-gnu/15.1.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/x86_64-linux-gnu/15.1.0/../../../../x86_64-linux-gnu/lib/:/opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/x86_64-linux-gnu/15.1.0/../../../:/lib/:/usr/l
[Bug c/120162] Prefetch causes vectorization to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120162 --- Comment #1 from Viktor Horsmanheimo --- Created attachment 61354 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61354&action=edit PoC in c++
[Bug libstdc++/120159] is_layout_compatible_v not exported in std module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120159 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |15.2 Last reconfirmed||2025-05-07
[Bug tree-optimization/120143] [15/16 Regression] ICE with -fwhole-program on undefined extern var in verify_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120143 --- Comment #5 from Richard Biener --- So the issue is that in vect_analyze_early_break_dependences we do stmt_vec_info stmt_vinfo = vect_stmt_to_vectorize (loop_vinfo->lookup_stmt (stmt)); and look at virtual operands of that stmt, but for the store # .MEM_22 = VDEF <.MEM_28> b[y_25][y_25] = _9; the pattern stmt is VIEW_CONVERT_EXPR(b[y_25][y_25]) = patt_1; note the lack of virtual operands here. But we need to move the original stmt in the end, not the pattern (which isn't in the IL anyway), and w/o a vdef we're not queueing the stmt. I think it's easiest to work with the original stmt throughout the function but have stmt_info be the stmt to vectorize.
[Bug c++/120125] [15/16 Regression] ICE in add_to_same_comdat_group when using -Os or -fdeclone-ctor-dtor since r15-521-g6ad7ca1bb90573
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120125 --- Comment #4 from Nathaniel Shead --- FWIW I have a WIP patch that fixes the ICE (also for the original testcase): diff --git a/gcc/cp/optimize.cc b/gcc/cp/optimize.cc index 6f9a77f407a..fc4d6c2e351 100644 --- a/gcc/cp/optimize.cc +++ b/gcc/cp/optimize.cc @@ -309,8 +309,8 @@ maybe_thunk_body (tree fn, bool force) defer_mangling_aliases = save_defer_mangling_aliases; cgraph_node::get_create (fns[0])->set_comdat_group (comdat_group); cgraph_node::get_create (fns[1])->add_to_same_comdat_group -(cgraph_node::get_create (fns[0])); - symtab_node::get (fn)->add_to_same_comdat_group +(cgraph_node::get (fns[0])); + symtab_node::get_create (fn)->add_to_same_comdat_group (symtab_node::get (fns[0])); if (fns[2]) /* If *[CD][12]* dtors go into the *[CD]5* comdat group and dtor is though I think there's another bigger issue somewhere to do with how we've handled imported explicit instantiations of inline constructors with '-fdeclone-ctor-dtor', as the generated code doesn't look right to me. Maybe this patch would be sufficient for backporting to 14/15 though.
[Bug lto/119956] lockfile / lto-ltrans-cache have poor testing coverage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119956 --- Comment #1 from Sam James --- This might be kind of easy to improve upon by extending lib/lto.exp's torture variants.
[Bug lto/119956] lockfile / lto-ltrans-cache have poor testing coverage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119956 Sam James changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-05-07 Ever confirmed|0 |1 Keywords||internal-improvement
[Bug jit/101491] /usr/local/include/libgccjit++.h conflicts between different GCC installations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491 --- Comment #14 from Sam James --- We've been moving it there for years downstream and had no problems.
[Bug c++/120125] [15/16 Regression] ICE in add_to_same_comdat_group when using -Os or -fdeclone-ctor-dtor since r15-521-g6ad7ca1bb90573
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120125 Sam James changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Sam James --- (In reply to mcccs from comment #2) > Bad commit: r15-521-g6ad7ca1bb90573 That commit has been backported as r14-11743-g6d5a6a26e28d15 which may mean it's a P1 on releases/gcc-14, but it's also modules, where IMO they can't be expected to work reasonably until 15 anyway as so much got fixed... jakub?
[Bug bootstrap/120145] Can't bootstrap gcc11 on OpenBSD / sparc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120145 --- Comment #6 from Kirill A. Korinsky --- I have backported both patch to used 8.4.0 as bootstrap compiler and 11.2.0 as target. It crashed the same way: Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/ports/pobj/gcc-11.2.0/build-sparc64/gcc/cc1... (gdb) r Starting program: /usr/ports/pobj/gcc-11.2.0/build-sparc64/gcc/cc1 Program received signal SIGSEGV, Segmentation fault. 0x00a16254c378 in _ZN8poly_intILj1ExEC1IiEERKT_+0xfcbb3c94@plt () (gdb) b _ZN8poly_intILj1ExEC1IiEERKT_+0xfcbb3c94@plt Breakpoint 1 at 0xa16254c368 (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/ports/pobj/gcc-11.2.0/build-sparc64/gcc/cc1 Breakpoint 1, 0x00670c44c368 in _ZN8poly_intILj1ExEC1IiEERKT_+0xfcbb3c94@plt () (gdb) c Continuing. Breakpoint 1, 0x00670c44c368 in _ZN8poly_intILj1ExEC1IiEERKT_+0xfcbb3c94@plt () (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x00670c44c378 in _ZN8poly_intILj1ExEC1IiEERKT_+0xfcbb3c94@plt () (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/ports/pobj/gcc-11.2.0/build-sparc64/gcc/cc1 Breakpoint 1, 0x0038ba64c368 in _ZN8poly_intILj1ExEC1IiEERKT_+0xfcbb3c94@plt () (gdb) c Continuing. Breakpoint 1, 0x0038ba64c368 in _ZN8poly_intILj1ExEC1IiEERKT_+0xfcbb3c94@plt () (gdb) bt #0 0x0038ba64c368 in _ZN8poly_intILj1ExEC1IiEERKT_+0xfcbb3c94@plt () #1 0x0038b82a25c0 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /usr/ports/pobj/gcc-11.2.0/gcc-11.2.0/gcc/ipa-modref-tree.h:95 #2 0x0038b82a2698 in _GLOBAL__sub_I__Z16dump_alias_statsP7__sFILE () at /usr/ports/pobj/gcc-11.2.0/gcc-11.2.0/gcc/tree-ssa-alias.c:4215 #3 0x0038b72006a4 in _start () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb)
[Bug fortran/119948] Source allocation of pure function result rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948 --- Comment #19 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:625b805544101ae90fbe789a5eeba44cd14e89fb commit r16-434-g625b805544101ae90fbe789a5eeba44cd14e89fb Author: Paul Thomas Date: Wed May 7 08:52:52 2025 +0100 Fortran: Source allocation of pure module function rejected [PR119948] 2025-05-07 Paul Thomas and Steven G. Kargl gcc/fortran PR fortran/119948 * primary.cc (match_variable): Module procedures with sym the same as result can be treated as variables, although marked external. gcc/testsuite/ PR fortran/119948 * gfortran.dg/pr119948.f90: Update to incorporate failing test, where module procedure is the result. Test submodule cases.
[Bug tree-optimization/118950] [14 regression] RISC-V: rv64gcv runtime mismatch at -O3 since r14-4038-gb975c0dc3be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950 --- Comment #13 from Robin Dapp --- Going to push this to the 14 branch later today if the x86 testsuite shows no regressions.
[Bug gcov-profile/118508] 10% performance drop when enabling autofdo for spec2017 554.roms_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118508 Hongtao Liu changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Hongtao Liu --- Fixed in GCC16.
[Bug gcov-profile/118508] 10% performance drop when enabling autofdo for spec2017 554.roms_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118508 --- Comment #1 from GCC Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:ae987baeb5fb70877fd007db80b77e374f676c76 commit r16-435-gae987baeb5fb70877fd007db80b77e374f676c76 Author: hongtao.liu Date: Tue Jan 14 01:13:22 2025 +0100 Fix name mismatch for fortran. Function name in afdo_string_table is step3d_t_tile. but DECL_ASSEMBLER_NAME (edge->callee->decl))) gets __step3d_t_mod_MOD_step3d_t_tile, Looks like the prefix is not in the debug string table. The patch uses afdo_string_table->get_index_by_decl (edge->callee->decl) instead. gcc/ChangeLog: PR gcov-profile/118508 * auto-profile.cc (autofdo_source_profile::get_callsite_total_count): Fix name mismatch for fortran.
[Bug tree-optimization/120135] Strange -Wuninitialized behavior with struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120135 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #7 from Manuel López-Ibáñez --- I cannot see the warning with x86-64 gcc 15.1 (or trunk or 14.1 or 12.1). Maybe ARM GCC is doing something different? But this should not be target-specific.
[Bug gcov-profile/118508] 10% performance drop when enabling autofdo for spec2017 554.roms_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118508 Sam James changed: What|Removed |Added Target Milestone|--- |16.0
[Bug ipa/120146] [15/16 Regression] ICE: SIGSEGV in all_refs_explicit_p (cgraph.h:3201) with -O -fopenacc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120146
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Component|tree-optimization |ipa
CC||hubicka at gcc dot gnu.org
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Last reconfirmed||2025-05-07
--- Comment #1 from Richard Biener ---
I'd guess openacc creates a global but does not create a varpool node for it
and thus
varpool_node *vnode = varpool_node::get (decl);
/* For escaped variables initialize them from nonlocal. */
if (!vnode->all_refs_explicit_p ())
make_copy_constraint (vi, nonlocal_id);
gets a NULL vnode.
Hmm, the decl is
$1 =
unit-size
which is referenced from the CONSTRUCTOR
{&MEM [(void *)&_ZTV14basic_ifstreamIcE + 24B], &MEM
[(void *)&_ZTC14basic_ifstreamIcE0_13basic_istream + 24B]}
of
$5 =
and -fopenacc simply enables early IPA PTA it seems:
PUSH_INSERT_PASSES_WITHIN (pass_ipa_oacc)
NEXT_PASS (pass_ipa_pta);
/* Pass group that runs when the function is an offloaded function
containing oacc kernels loops. */
NEXT_PASS (pass_ipa_oacc_kernels);
...
Likely caused by my fix for PR119973. I'm not sure why the variables
referenced in the global var initializer are not finalized? I see
_ZTT14basic_ifstreamIcE/17 (constexpr const void*
basic_ifstream::_ZTT14basic_ifstreamIcE [2])
Type: variable definition analyzed
Visibility: semantic_interposition external public virtual artificial
Aux: @0x4f8c200
References: _ZTV14basic_ifstreamIcE/8 (addr)
_ZTC14basic_ifstreamIcE0_13basic_istream/20 (addr)
But at the time IPA PTA runs the symbol is elided, but the reference through
the CTOR is still there? That is, DECL_INITIAL isn't pruned? At the
IPA PTA point the variable refering to the elided node is
_ZTT14basic_ifstreamIcE/17 (constexpr const void*
basic_ifstream::_ZTT14basic_ifstreamIcE [2])
Type: variable
Body removed by symtab_remove_unreachable_nodes
Visibility: externally_visible semantic_interposition external public virtual
artificial
References:
Referring: _Z18CompareFiles_path2v/7 (read)
Availability: not_available
Varpool flags: initialized read-only const-value-known
so it's const-value-known, but it no longer has references (from said
initializer) and it's not_available, whatever that means.
IPA PTA in it's walk over globals still does the following, not sure
if it should skip some variables. The one in question has !var->analyzed
for example, for whatever reason.
/* Create constraints for global variables and their initializers. */
FOR_EACH_VARIABLE (var)
{
if (var->alias && var->analyzed)
continue;
varinfo_t vi = get_vi_for_tree (var->decl);
/* For the purpose of IPA PTA unit-local globals are not
escape points. */
bool nonlocal_p = (DECL_EXTERNAL (var->decl)
|| TREE_PUBLIC (var->decl)
|| var->used_from_other_partition
|| var->force_output);
var->call_for_symbol_and_aliases (refered_from_nonlocal_var,
&nonlocal_p, true);
if (nonlocal_p)
vi->is_ipa_escape_point = true;
}
Not processing globals with !var->analyzed does not help since we still
refer to those from the IL (CompareFiles_path2):
# VUSE <.MEM_2>
_4 = MEM[(const void * *)&_ZTT14basic_ifstreamIcE + 8B];
so why was the varpool node "elided"? Or why is it not analyzed/available?
I'm confused.
I can paper over the ICE by simply "dealing" with a NULL varpool node
but I think this is just playing whack-a-mole without understanding
what IPA does here :/
"Fix:"
diff --git a/gcc/tree-ssa-structalias.cc b/gcc/tree-ssa-structalias.cc
index 3ad0c69930c..1a6522593ba 100644
--- a/gcc/tree-ssa-structalias.cc
+++ b/gcc/tree-ssa-structalias.cc
@@ -6562,7 +6562,7 @@ create_variable_info_for (tree decl, const char *name,
bool add_id)
varpool_node *vnode = varpool_node::get (decl);
/* For escaped variables initialize them from nonlocal. */
- if (!vnode->all_refs_explicit_p ())
+ if (!vnode || !vnode->all_refs_explicit_p ())
make_copy_constraint (vi, nonlocal_id);
/* While we can in theory walk references for the varpool
@@ -6581,7 +6581,7 @@ create_variable_info_for (tree decl, const char *name,
bool add_id)
process_constraint (new_constraint (lhs, *rhsp));
/* If this is a variable that escapes from the unit
the initializer escapes as well. */
- if (!vnode->all_refs_explicit_p ())
+ if (!vnode || !vnode->all_r
[Bug driver/120148] New: -fno-builtin suppresses -Wformat warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120148
Bug ID: 120148
Summary: -fno-builtin suppresses -Wformat warnings
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: flo2...@eich-krohm.de
Target Milestone: ---
Reproducer:
extern int printf(const char *, ...);
int main(void)
{
return printf("%s\n", 10);
}
When compiled with -Wformat like so:
gcc -Wformat test.c
test.c: In function ‘main’:
test.c:5:20: warning: format ‘%s’ expects argument of type ‘char *’, but
argument 2 has type ‘int’ [-Wformat=]
a warning is given as expected.
Adding -fno-builtin to the command line and the warning no longer shows up.
gcc -Wformat -fno-builtin test.c
The order of command line options is irrelevant.
This happens with 15.1.0 built from tarball. It is not new. 11.4.0 also has
this problem.
Observed on x86_64-linux-gnu and s390x-ibm-linux-gnu.
[Bug driver/120148] -fno-builtin suppresses -Wformat warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120148 --- Comment #1 from Florian Krohm --- Created attachment 61349 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61349&action=edit gcc -v output
[Bug target/120036] [16 Regression] ICE on highway-1.2.0: during RTL pass: rrvl: in gen_rtx_SUBREG, at emit-rtl.cc:1032 since r16-271-gd1cada7481420a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120036 --- Comment #7 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:b8c4b6aa8e0521770c6f9fd48dd13dd85e3a2fc9 commit r16-436-gb8c4b6aa8e0521770c6f9fd48dd13dd85e3a2fc9 Author: H.J. Lu Date: Thu May 1 06:30:41 2025 +0800 x86: Insert extra move for mode size smaller than natural size When generating a SUBREG from V16QI to V2HF, validate_subreg fails since V2HF is a floating point vector and its size (4 bytes) is smaller than its natural size (word size). Insert an extra move with a QI vector SUBREG of the same size to avoid validate_subreg failure. gcc/ PR target/120036 * config/i386/i386-features.cc (ix86_get_vector_load_mode): Handle 8/4/2 bytes. (remove_redundant_vector_load): If the mode size is smaller than its natural size, first insert an extra move with a QI vector SUBREG of the same size to avoid validate_subreg failure. gcc/testsuite/ PR target/120036 * g++.target/i386/pr120036.C: New test. * gcc.target/i386/pr117839-3a.c: Likewise. * gcc.target/i386/pr117839-3b.c: Likewise. Signed-off-by: H.J. Lu
[Bug ipa/120146] [15/16 Regression] ICE: SIGSEGV in all_refs_explicit_p (cgraph.h:3201) with -O -fopenacc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120146 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #2 from Richard Biener --- P1 for 15.2
[Bug target/120036] [16 Regression] ICE on highway-1.2.0: during RTL pass: rrvl: in gen_rtx_SUBREG, at emit-rtl.cc:1032 since r16-271-gd1cada7481420a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120036 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #8 from H.J. Lu --- Please verify if the current master branch has been fixed.
[Bug c++/120149] New: ICE in GCC when deducing return type with nested lambdas using accumulate with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120149
Bug ID: 120149
Summary: ICE in GCC when deducing return type with nested
lambdas using accumulate with -std=c++20
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
Compiling the following valid C++ code causes an internal compiler error (ICE)
in recent versions of GCC
```
#include
#include
using namespace std;
template
auto f(A a, B b)
-> decltype(accumulate(begin(a), end(a), B{},
[](B t, A i) -> B
{
return t + i * i;
}))
{
}
int main()
{
vector v;
int i;
f(v, i);
return 0;
}
```
```
internal compiler error: error reporting routines re-entered.
0x228730d diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2287465 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x22983b0 error_at(rich_location*, char const*, ...)
???:0
0x8063af build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0xa049f2 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0x9b8831 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x9ab9bc tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x22a4c53 pretty_printer::format(text_info&)
???:0
0x22a6ed3 pp_verbatim(pretty_printer*, char const*, ...)
???:0
0x2296158 diagnostic_text_output_format::on_report_diagnostic(diagnostic_info
const&, diagnostic_t)
???:0
0x2287092 diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2287465 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x229746e warning_at(rich_location*, diagnostic_option_id, char const*, ...)
???:0
0x884c40 finish_function(bool)
???:0
0x99f62f instantiate_decl(tree_node*, bool, bool)
???:0
0x9c5b03 instantiate_pending_templates(int)
???:0
0x898b1a c_parse_final_cleanups()
???:0
0xa8b768 c_common_parse_file()
???:0
```
To reproduce:
Happens since gcc 10, the first version that accepts -std=c++20
https://gcc.godbolt.org/z/GMnch3Evo
[Bug c++/120150] New: ICE in GCC when deducing return type with nested lambdas using accumulate with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120150
Bug ID: 120150
Summary: ICE in GCC when deducing return type with nested
lambdas using accumulate with -std=c++20
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
Compiling the following valid C++ code causes an internal compiler error (ICE)
in recent versions of GCC
```
#include
#include
using namespace std;
template
auto f(A a, B b)
-> decltype(accumulate(begin(a), end(a), B{},
[](B t, A i) -> B
{
return t + i * i;
}))
{
}
int main()
{
vector v;
int i;
f(v, i);
return 0;
}
```
```
internal compiler error: error reporting routines re-entered.
0x228730d diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2287465 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x22983b0 error_at(rich_location*, char const*, ...)
???:0
0x8063af build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0xa049f2 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0x9b8831 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x9ab9bc tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x22a4c53 pretty_printer::format(text_info&)
???:0
0x22a6ed3 pp_verbatim(pretty_printer*, char const*, ...)
???:0
0x2296158 diagnostic_text_output_format::on_report_diagnostic(diagnostic_info
const&, diagnostic_t)
???:0
0x2287092 diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2287465 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x229746e warning_at(rich_location*, diagnostic_option_id, char const*, ...)
???:0
0x884c40 finish_function(bool)
???:0
0x99f62f instantiate_decl(tree_node*, bool, bool)
???:0
0x9c5b03 instantiate_pending_templates(int)
???:0
0x898b1a c_parse_final_cleanups()
???:0
0xa8b768 c_common_parse_file()
???:0
```
To reproduce:
Happens since gcc 10, the first version that accepts -std=c++20
https://gcc.godbolt.org/z/GMnch3Evo
[Bug target/120137] [16 regression] RISC-V: ICE during RTL pass: vect_permconst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120137 Richard Biener changed: What|Removed |Added Target||riscv Target Milestone|--- |16.0 Keywords||ice-on-valid-code
[Bug c++/120133] [12/13/14/15 regression] internal compiler error: Segmentation fault signal terminated program cc1plus since r9-6542-gf869f40780836d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120133 Richard Biener changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P4
[Bug libstdc++/120147] [16 Regression] libstdc++-v3 build failure for mingw32 target: src/c++23/print.cc:102:49: error: invalid conversion from 'std::basic_filebuf::native_handle_type' {aka 'int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120147 --- Comment #2 from Jonathan Wakely --- I don't see how that commit can cause this. The native_handle_type is determined by: #ifdef _GLIBCXX_USE_STDIO_PURE using native_handle_type = __c_file*; // FILE* #elif _GLIBCXX_USE__GET_OSFHANDLE using native_handle_type = void*; // HANDLE #else using native_handle_type = int; // POSIX file descriptor #endif And the _GLIBCXX_USE__GET_OSFHANDLE macro should be defined on Windows, as decided by this autoconf test: AC_TRY_COMPILE([ #if defined(_WIN32) && !defined(__CYGWIN__) # include # include # include #endif ],[ FILE* file = 0; int fd = fileno(file); intptr_t crt_handle = _get_osfhandle(fd); void* win32_handle = reinterpret_cast(crt_handle); ], [ac_get_osfhandle=yes], [ac_get_osfhandle=no]) if test "$ac_get_osfhandle" = yes; then AC_DEFINE_UNQUOTED(_GLIBCXX_USE__GET_OSFHANDLE, 1, [Define if _get_osfhandle should be used for filebuf::native_handle().]) fi This has nothing to do with atomic builtins.
[Bug tree-optimization/120143] [15/16 Regression] ICE with -fwhole-program on undefined extern var in verify_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120143 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- I will have a look.
[Bug c++/118964] include in the module causes a compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118964 XU Kailiang changed: What|Removed |Added CC||xu2k3l4 at outlook dot com --- Comment #7 from XU Kailiang --- (In reply to printfne from comment #3) > g++ main.cpp Camera.cpp Image.cpp MultArray.cpp -fmodules-ts > > This compile command needs to be executed twice. The first command generates > an error and creates the gcm.cache folder. The second command reproduces the > above error message. Unable to reproduce on gcc 15.1.1. Is it already fixed? opencv 4.11.0-9 gcc15.1.1
[Bug c++/120142] [13/14/15/16 regression] internal compiler error: in tsubst, at cp/pt.cc:16670 since r13-6971-ga5de246535db1b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120142 Sam James changed: What|Removed |Added Summary|internal compiler error: in |[13/14/15/16 regression] |tsubst, at cp/pt.cc:16670 |internal compiler error: in ||tsubst, at cp/pt.cc:16670 ||since ||r13-6971-ga5de246535db1b Target Milestone|--- |13.4 CC||ppalka at gcc dot gnu.org
[Bug tree-optimization/120138] [14/15/16 regression] -Wmaybe-uninitialized triggered after specific optimizations since r14-4089-gd45ddc2c04e471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120138 Sam James changed: What|Removed |Added Target Milestone|--- |14.3 Summary|(14/15/16) |[14/15/16 regression] |-Wmaybe-uninitialized |-Wmaybe-uninitialized |triggered after specific|triggered after specific |optimizations |optimizations since ||r14-4089-gd45ddc2c04e471
[Bug c++/118964] include in the module causes a compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118964 Nathaniel Shead changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from Nathaniel Shead --- Yes, the error is no longer reported since r15-7906-gb360d4aafc1356386313c7392f7444b3fc356681, so closing. Though as Jason noted we probably should be erroring (or at least warning) here anyway, but I don't think that is necessarily helpful; regardless, that could be a separate report.
[Bug libstdc++/120147] [16 Regression] libstdc++-v3 build failure for mingw32 target: src/c++23/print.cc:102:49: error: invalid conversion from 'std::basic_filebuf::native_handle_type' {aka 'int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120147 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-05-07 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- And yet somehow it does. Confirmed.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 118964, which changed state. Bug 118964 Summary: include in the module causes a compilation error https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118964 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/120147] [16 Regression] libstdc++-v3 build failure for mingw32 target: src/c++23/print.cc:102:49: error: invalid conversion from 'std::basic_filebuf::native_handle_type' {aka 'int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120147 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |16.0
[Bug c++/120149] ICE in GCC when deducing return type with nested lambdas using accumulate with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120149 --- Comment #1 from MARIO RODRIGUEZ BEJAR --- *** Bug 120150 has been marked as a duplicate of this bug. ***
[Bug c++/120150] ICE in GCC when deducing return type with nested lambdas using accumulate with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120150 MARIO RODRIGUEZ BEJAR changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from MARIO RODRIGUEZ BEJAR --- I submitted the same twice, i apologize *** This bug has been marked as a duplicate of bug 120149 ***
[Bug driver/120148] -fno-builtin suppresses -Wformat warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120148 Andreas Schwab changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andreas Schwab --- You need to declare printf with __attribute__((format)) to get the warning. By using -fno-builtin the declaration of printf just declares a random function with no other special properties.
[Bug c++/120151] New: ICE in GCC when compiling a templated decltype with incomplete lambda body with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120151
Bug ID: 120151
Summary: ICE in GCC when compiling a templated decltype with
incomplete lambda body with -std=c++20
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
It is interesting the fact that this ICE arises from the same program as
#120149 but removing a line, resulting in a totally different stack dump
```
#include
#include
#include
using namespace std;
template
auto f(A a, B b)
-> decltype(accumulate(begin(a), end(a), B{},
[](B t, A i) -> B
{
}))
{
}
int main()
{
vector v;
int i;
f(v, i);
}
```
Stack dump
```
internal compiler error: error reporting routines re-entered.
0x228730d diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2287465 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x229746e warning_at(rich_location*, diagnostic_option_id, char const*, ...)
???:0
0x884c40 finish_function(bool)
???:0
0x8bb3dc finish_lambda_function(tree_node*)
???:0
0x9b883b tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x9ab9bc tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x22a4c53 pretty_printer::format(text_info&)
???:0
0x22a6ed3 pp_verbatim(pretty_printer*, char const*, ...)
???:0
0x2296158 diagnostic_text_output_format::on_report_diagnostic(diagnostic_info
const&, diagnostic_t)
???:0
0x2287092 diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2287465 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x229746e warning_at(rich_location*, diagnostic_option_id, char const*, ...)
???:0
0x884c40 finish_function(bool)
???:0
0x99f62f instantiate_decl(tree_node*, bool, bool)
???:0
0x9c5b03 instantiate_pending_templates(int)
???:0
0x898b1a c_parse_final_cleanups()
???:0
0xa8b768 c_common_parse_file()
???:0
```
To quickly reproduce
https://gcc.godbolt.org/z/v5v37qhdo
[Bug c++/120134] internal compiler error: in coerce_template_parms, at cp/pt.cc:9488
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120134 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #1 from mcccs at gmx dot com --- bisect bad commit: r14-2170-g4cf64d9cc2faf4
[Bug fortran/120152] New: [15/16 Regression] libgfortran ABI problem starting with r15-4124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120152 Bug ID: 120152 Summary: [15/16 Regression] libgfortran ABI problem starting with r15-4124 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- Comparing libgfortran.so.5.0.0 abilist between 14 and 15, I see in addition to many expectedly added symbols (surprisingly also +_gfortran_selected_logical_kind@@GFORTRAN_14 FUNC GLOBAL DEFAULT where 14 didn't have any GFORTRAN_14 symbols and 15 has one) I see 15 symbols removed: -_gfortran_maxloc1_16_i8@@GFORTRAN_8 FUNC GLOBAL DEFAULT -_gfortran_maxloc1_4_i16@@GFORTRAN_8 FUNC GLOBAL DEFAULT -_gfortran_maxloc1_4_i8@@GFORTRAN_8 FUNC GLOBAL DEFAULT -_gfortran_maxloc1_8_i16@@GFORTRAN_8 FUNC GLOBAL DEFAULT -_gfortran_maxloc1_8_i8@@GFORTRAN_8 FUNC GLOBAL DEFAULT -_gfortran_mmaxloc1_16_i8@@GFORTRAN_8 FUNC GLOBAL DEFAULT -_gfortran_mmaxloc1_4_i16@@GFORTRAN_8 FUNC GLOBAL DEFAULT -_gfortran_mmaxloc1_4_i8@@GFORTRAN_8 FUNC GLOBAL DEFAULT -_gfortran_mmaxloc1_8_i16@@GFORTRAN_8 FUNC GLOBAL DEFAULT -_gfortran_mmaxloc1_8_i8@@GFORTRAN_8 FUNC GLOBAL DEFAULT -_gfortran_smaxloc1_16_i8@@GFORTRAN_8 FUNC GLOBAL DEFAULT -_gfortran_smaxloc1_4_i16@@GFORTRAN_8 FUNC GLOBAL DEFAULT -_gfortran_smaxloc1_4_i8@@GFORTRAN_8 FUNC GLOBAL DEFAULT -_gfortran_smaxloc1_8_i16@@GFORTRAN_8 FUNC GLOBAL DEFAULT -_gfortran_smaxloc1_8_i8@@GFORTRAN_8 FUNC GLOBAL DEFAULT
[Bug fortran/120152] [15/16 Regression] libgfortran ABI problem starting with r15-4124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120152 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org CC||tkoenig at gcc dot gnu.org Priority|P3 |P1 Target Milestone|--- |15.2 Ever confirmed|0 |1 Last reconfirmed||2025-05-07 Status|UNCONFIRMED |ASSIGNED
[Bug tree-optimization/120080] [16 regression] ICE when building llvm-20.1.3 (find_bit_tests, at tree-switch-conversion.cc:1799) since r16-347-g1381a5114788a2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120080 --- Comment #10 from Filip Kastl --- The line that crashes GCC seems to be this one gcc_checking_assert (l > 0); where l is the number of clusters of a switch. At this point in compilation clusters = cases so this means that bit-test switch lowering ran into a switch without cases. This should work as a trivial fix: Replace the crashing line with if (l == 0) return clusters.copy(); I'll bootstrap and regtest this fix and then I'll push it. I thought that switch lowering shouldn't run into empty switches (can't recall what made me think that though). I'll look into why that happens.
[Bug tree-optimization/120156] New: [14 Regression] Segfault while compiling eigen test bdcsvd.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120156
Bug ID: 120156
Summary: [14 Regression] Segfault while compiling eigen test
bdcsvd.cpp
Product: gcc
Version: 14.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at gcc dot gnu.org
Target Milestone: ---
While running the eigen testsuite
(https://gitlab.com/libeigen/eigen/-/commit/729443409942a1816ddf74b95224003b83f4925c
plus an internal patch) results in a segfault while using gcc 14 (commit
r14-11745-g93b85bdf830477):
c++ -DEIGEN_TEST_MAX_SIZE=320 -DEIGEN_TEST_PART_16=1 -I/devel/eigen -pedantic
-Wall -Wextra -Wundef -Wcast-align -Wchar-subscripts -Wnon-virtual-dtor
-Wunused-local-typedefs -Wpointer-arith -Wwrite-strings -Wformat-security
-Wlogical-op -Wenum-conversion -Wc++11-extensions -Wdouble-promotion -Wshadow
-Wno-psabi -Wno-variadic-macros -Wno-long-long -fno-common -fstrict-aliasing
-fno-check-new -march=z13 -mzvector -march=z14 -mzvector -O3 -DNDEBUG
-std=c++14 -MD -MT test/CMakeFiles/bdcsvd_16.dir/bdcsvd.cpp.o -MF
CMakeFiles/bdcsvd_16.dir/bdcsvd.cpp.o.d -o
CMakeFiles/bdcsvd_16.dir/bdcsvd.cpp.o -c /devel/eigen/test/bdcsvd.cpp
...
/devel/eigen/Eigen/src/SVD/SVDBase.h:372:6: internal compiler error:
Segmentation fault
372 | void SVDBase::_solve_impl(const RhsType& rhs, DstType& dst)
const {
| ^~~~
0x1abbc09 crash_signal
/devel/gcc-2-eigen/src/gcc/toplev.cc:319
0x1537dc2 bitmap_list_find_element
/devel/gcc-2-eigen/src/gcc/bitmap.cc:397
0x1537dc2 bitmap_bit_p(bitmap_head const*, int)
/devel/gcc-2-eigen/src/gcc/bitmap.cc:995
0x1cf0deb pt_solution_includes_1
/devel/gcc-2-eigen/src/gcc/tree-ssa-structalias.cc:7050
0x1cf8d81 pt_solution_includes(pt_solution*, tree_node const*)
/devel/gcc-2-eigen/src/gcc/tree-ssa-structalias.cc:7069
0x25ad6a5 initialize_data_dependence_relation(data_reference*, data_reference*,
vec)
/devel/gcc-2-eigen/src/gcc/tree-data-ref.cc:3498
0x25ad7ad compute_all_dependences(vec const&,
vec*, vec
const&, bool)
/devel/gcc-2-eigen/src/gcc/tree-data-ref.cc:5771
0x25ad7ad compute_all_dependences(vec const&,
vec*, vec
const&, bool)
/devel/gcc-2-eigen/src/gcc/tree-data-ref.cc:5746
0x1c5bb6b determine_loop_nest_reuse
/devel/gcc-2-eigen/src/gcc/tree-ssa-loop-prefetch.cc:1689
0x1c5bb6b loop_prefetch_arrays
/devel/gcc-2-eigen/src/gcc/tree-ssa-loop-prefetch.cc:1935
0x1c5bb6b tree_ssa_prefetch_arrays()
/devel/gcc-2-eigen/src/gcc/tree-ssa-loop-prefetch.cc:2037
Oddly preprocessing the file and then compiling the preprocessed file succeeds.
Compilation also succeeds with gcc 15. Bisect stops at
r15-491-gc290e6a0b7a9de. Backporting this commit fixes the segfault for me.
[Bug libstdc++/107761] Implement C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761 --- Comment #9 from Jonathan Wakely --- (In reply to Desmond Gold from comment #3) > I've implemented c++23 features for in libstdc++ (hopefully) which > is inspired by other reference implementations (libc++, STL, Kokkos). > > https://godbolt.org/z/Gc8vvjaT9 > > however: > + no optimizations yet (this includes SBO) > + no 'stronger' and complete tests yet > + no documentation yet > + some assertions have no messages There are threads on the mailing list where a new implementation is being worked on. If you're like to contribute to that, please do join in on the email thread.
[Bug tree-optimization/120156] [14 Regression] Segfault while compiling eigen test bdcsvd.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120156 --- Comment #1 from Stefan Schulze Frielinghaus --- I will try to reduce the test.
[Bug middle-end/108016] RISC-V：Bad codegen in scalar code comparing to LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108016
--- Comment #13 from Alexey Merzlyakov
---
> There is https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660968.html
> which (though I am not 100% sure) will help the situtation.
Thank you for the reference, this definitely makes sense.
If I understood correctly, this patch does 2 things: re-assignment of function
input arguments passed from registers and making the return value to be passed
via output register(s). The first thing of the patch caused unnecessary SP
addressing for RISC-V on the example like:
typedef struct { long long a[4]; } A;
typedef struct { A a; long long b; } B;
A fun6 (const B b) { return b.a; }
... as it seem to make rhs part of the input arg as MEM_REF type, that will be
reflected on the frame by "expand" and optimized-out by "DSE" later; but still
unnecessary SP-allocation will remain.
However, the second part of optimization of the returning value to be passed
via register(s) seems to be exactly what we need. The patch fixes all local
cases with return values I have, including the cases where return structure is
being fully packed on an output register that my previously proposed
optimization did not. FSRA patch still not resolve "Item2" case reported above,
but fixes "Item1" (I believe that for "Item2" frame_offset could be
re-calculated during FSRA stage when optimizing output parameters, but this
need to be additionally checked).
The patch seem to be abandoned since Sep-2024, so not sure how could we go on,
maybe contact author of the original patch about upstream plans.
[Bug target/117978] Optimise 128-bit-predicated SVE loads to Advanced SIMD LDRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117978
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jennifer Schmitz :
https://gcc.gnu.org/g:210d06502f22964c7214586c54f8eb54a6965bfd
commit r16-446-g210d06502f22964c7214586c54f8eb54a6965bfd
Author: Jennifer Schmitz
Date: Fri Feb 14 00:46:13 2025 -0800
AArch64: Fold SVE load/store with certain ptrue patterns to LDR/STR.
SVE loads/stores using predicates that select the bottom 8, 16, 32, 64,
or 128 bits of a register can be folded to ASIMD LDR/STR, thus avoiding the
predicate.
For example,
svuint8_t foo (uint8_t *x) {
return svld1 (svwhilelt_b8 (0, 16), x);
}
was previously compiled to:
foo:
ptrue p3.b, vl16
ld1bz0.b, p3/z, [x0]
ret
and is now compiled to:
foo:
ldr q0, [x0]
ret
The optimization is applied during the expand pass and was implemented
by making the following changes to maskload and
maskstore:
- the existing define_insns were renamed and new define_expands for
maskloads
and maskstores were added with nonmemory_operand as predicate such that
the
SVE predicate matches both register operands and constant-vector
operands.
- if the SVE predicate is a constant vector and contains a pattern as
described above, an ASIMD load/store is emitted instead of the SVE
load/store.
The patch implements the optimization for LD1 and ST1, for 8-bit, 16-bit,
32-bit, 64-bit, and 128-bit moves, for all full SVE data vector modes.
Follow-up patches for LD2/3/4 and ST2/3/4 and potentially partial SVE
vector
modes are planned.
The patch was bootstrapped and tested on aarch64-linux-gnu, no regression.
Signed-off-by: Jennifer Schmitz
gcc/
PR target/117978
* config/aarch64/aarch64-protos.h: Declare
aarch64_emit_load_store_through_mode and aarch64_sve_maskloadstore.
* config/aarch64/aarch64-sve.md
(maskload): New define_expand folding maskloads with
certain predicate patterns to ASIMD loads.
(*aarch64_maskload): Renamed from
maskload.
(maskstore): New define_expand folding maskstores with
certain predicate patterns to ASIMD stores.
(*aarch64_maskstore): Renamed from
maskstore.
* config/aarch64/aarch64.cc
(aarch64_emit_load_store_through_mode): New function emitting a
load/store through subregs of a given mode.
(aarch64_emit_sve_pred_move): Refactor to use
aarch64_emit_load_store_through_mode.
(aarch64_expand_maskloadstore): New function to emit ASIMD
loads/stores
for maskloads/stores with SVE predicates with VL1, VL2, VL4, VL8,
or
VL16 patterns.
(aarch64_partial_ptrue_length): New function returning number of
leading
set bits in a predicate.
gcc/testsuite/
PR target/117978
* gcc.target/aarch64/sve/acle/general/whilelt_5.c: Adjust expected
outcome.
* gcc.target/aarch64/sve/ldst_ptrue_pat_128_to_neon.c: New test.
* gcc.target/aarch64/sve/while_7.c: Adjust expected outcome.
* gcc.target/aarch64/sve/while_9.c: Adjust expected outcome.
[Bug target/120137] [16 regression] RISC-V: ICE during RTL pass: vect_permconst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120137 Jeffrey A. Law changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #2 from Jeffrey A. Law --- *** Bug 120154 has been marked as a duplicate of this bug. ***
[Bug preprocessor/116047] C preprocessor bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116047
--- Comment #6 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:edf745dc519ddbfef127e2789bf11bfbacd300b7
commit r16-450-gedf745dc519ddbfef127e2789bf11bfbacd300b7
Author: Jakub Jelinek
Date: Wed May 7 17:25:42 2025 +0200
libcpp: Further fixes for incorrect line numbers in large files [PR120061]
The backport of the PR108900 fix to 14 branch broke building chromium
because static_assert (__LINE__ == expected_line_number, ""); now triggers
as the __LINE__ values are off by one.
This isn't the case on the trunk and 15 branch because we've switched
to 64-bit location_t and so one actually needs far longer header files
to trigger it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12
contain (large) testcases in patch form which show on the 14 branch
that the first one used to fail before the PR108900 backport and now
works correctly, while the second one attempts to match the chromium
behavior and it used to pass before the PR108900 backport and now it
FAILs.
The two testcases show rare problematic cases, because
do_include_common -> parse_include -> check_eol -> check_eol_1 ->
cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start
triggers there
/* Allocate the new line_map. However, if the current map only has a
single line we can sometimes just increase its column_bits
instead. */
if (line_delta < 0
|| last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map)
|| SOURCE_COLUMN (map, highest) >= (1U << (column_bits -
range_bits))
|| ( /* We can't reuse the map if the line offset is sufficiently
large to cause overflow when computing location_t values.
*/
(to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map))
>= (((uint64_t) 1)
<< (CHAR_BIT * sizeof (linenum_type) - column_bits)))
|| range_bits < map->m_range_bits)
map = linemap_check_ordinary
(const_cast
(linemap_add (set, LC_RENAME,
ORDINARY_MAP_IN_SYSTEM_HEADER_P (map),
ORDINARY_MAP_FILE_NAME (map),
to_line)));
and so creates a new ordinary map on the line right after the
(problematic) #include line.
Now, in the spot that r14-11679-g8a884140c2bcb7 patched,
pfile->line_table->highest_location in all 3 tests (also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c13
) is before the decrement the start of the line after the #include line and
so
the decrement is really desirable in that case to put highest_location
somewhere on the line where the #include actually is.
But at the same time it is also undesirable, because if we do decrement it,
then linemap_add LC_ENTER called from _cpp_do_file_change will then
/* Generate a start_location above the current highest_location.
If possible, make the low range bits be zero. */
location_t start_location = set->highest_location + 1;
unsigned range_bits = 0;
if (start_location < LINE_MAP_MAX_LOCATION_WITH_COLS)
range_bits = set->default_range_bits;
start_location += (1 << range_bits) - 1;
start_location &= ~((1 << range_bits) - 1);
linemap_assert (!LINEMAPS_ORDINARY_USED (set)
|| (start_location
>= MAP_START_LOCATION (LINEMAPS_LAST_ORDINARY_MAP
(set;
and we can end up with the new LC_ENTER ordinary map having the same
start_location as the preceding LC_RENAME one.
Next thing that happens is computation of included_from:
if (reason == LC_ENTER)
{
if (set->depth == 0)
map->included_from = 0;
else
/* The location of the end of the just-closed map. */
map->included_from
= (((map[0].start_location - 1 - map[-1].start_location)
& ~((1 << map[-1].m_column_and_range_bits) - 1))
+ map[-1].start_location);
The normal case (e.g. with the testcase included at the start of this
comment) is
that map[-1] starts somewhere earlier and so map->included_from computation
above
nicely computes location_t which expands to the start of the #include line.
With r14-11679 reverted, for #c11 as well as #c12
map[0].start_location == map[-1].start_location above, and so it is
((location_t) -1 & ~((1 << map[-1].m_column_and_range_bits) - 1)))
+ map[-1].start_location,
which happens to be start of the #include line.
For #c11 map[0].start_location is 0x53a0 and map[-1] has
m_column_and_range_bits 7 and map[-2] has m_column_and_range_bits 12 and
m
[Bug preprocessor/108900] [libcpp] cpp gives wrong line number information with a file huge number of lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108900
--- Comment #19 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:edf745dc519ddbfef127e2789bf11bfbacd300b7
commit r16-450-gedf745dc519ddbfef127e2789bf11bfbacd300b7
Author: Jakub Jelinek
Date: Wed May 7 17:25:42 2025 +0200
libcpp: Further fixes for incorrect line numbers in large files [PR120061]
The backport of the PR108900 fix to 14 branch broke building chromium
because static_assert (__LINE__ == expected_line_number, ""); now triggers
as the __LINE__ values are off by one.
This isn't the case on the trunk and 15 branch because we've switched
to 64-bit location_t and so one actually needs far longer header files
to trigger it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12
contain (large) testcases in patch form which show on the 14 branch
that the first one used to fail before the PR108900 backport and now
works correctly, while the second one attempts to match the chromium
behavior and it used to pass before the PR108900 backport and now it
FAILs.
The two testcases show rare problematic cases, because
do_include_common -> parse_include -> check_eol -> check_eol_1 ->
cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start
triggers there
/* Allocate the new line_map. However, if the current map only has a
single line we can sometimes just increase its column_bits
instead. */
if (line_delta < 0
|| last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map)
|| SOURCE_COLUMN (map, highest) >= (1U << (column_bits -
range_bits))
|| ( /* We can't reuse the map if the line offset is sufficiently
large to cause overflow when computing location_t values.
*/
(to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map))
>= (((uint64_t) 1)
<< (CHAR_BIT * sizeof (linenum_type) - column_bits)))
|| range_bits < map->m_range_bits)
map = linemap_check_ordinary
(const_cast
(linemap_add (set, LC_RENAME,
ORDINARY_MAP_IN_SYSTEM_HEADER_P (map),
ORDINARY_MAP_FILE_NAME (map),
to_line)));
and so creates a new ordinary map on the line right after the
(problematic) #include line.
Now, in the spot that r14-11679-g8a884140c2bcb7 patched,
pfile->line_table->highest_location in all 3 tests (also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c13
) is before the decrement the start of the line after the #include line and
so
the decrement is really desirable in that case to put highest_location
somewhere on the line where the #include actually is.
But at the same time it is also undesirable, because if we do decrement it,
then linemap_add LC_ENTER called from _cpp_do_file_change will then
/* Generate a start_location above the current highest_location.
If possible, make the low range bits be zero. */
location_t start_location = set->highest_location + 1;
unsigned range_bits = 0;
if (start_location < LINE_MAP_MAX_LOCATION_WITH_COLS)
range_bits = set->default_range_bits;
start_location += (1 << range_bits) - 1;
start_location &= ~((1 << range_bits) - 1);
linemap_assert (!LINEMAPS_ORDINARY_USED (set)
|| (start_location
>= MAP_START_LOCATION (LINEMAPS_LAST_ORDINARY_MAP
(set;
and we can end up with the new LC_ENTER ordinary map having the same
start_location as the preceding LC_RENAME one.
Next thing that happens is computation of included_from:
if (reason == LC_ENTER)
{
if (set->depth == 0)
map->included_from = 0;
else
/* The location of the end of the just-closed map. */
map->included_from
= (((map[0].start_location - 1 - map[-1].start_location)
& ~((1 << map[-1].m_column_and_range_bits) - 1))
+ map[-1].start_location);
The normal case (e.g. with the testcase included at the start of this
comment) is
that map[-1] starts somewhere earlier and so map->included_from computation
above
nicely computes location_t which expands to the start of the #include line.
With r14-11679 reverted, for #c11 as well as #c12
map[0].start_location == map[-1].start_location above, and so it is
((location_t) -1 & ~((1 << map[-1].m_column_and_range_bits) - 1)))
+ map[-1].start_location,
which happens to be start of the #include line.
For #c11 map[0].start_location is 0x53a0 and map[-1] has
m_column_and_range_bits 7 and map[-2] has m_column_and_range_bits 12 and
[Bug libfortran/120158] Incorrect UNSIGNED maxval/maxloc etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120158 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2025-05-07 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jakub Jelinek --- Created attachment 61353 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61353&action=edit gcc16-pr120158.patch Untested fix.
[Bug preprocessor/120061] [14 Regression] libqt6webengine fails static_assert (__LINE__ == 470, ...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061
--- Comment #21 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:edf745dc519ddbfef127e2789bf11bfbacd300b7
commit r16-450-gedf745dc519ddbfef127e2789bf11bfbacd300b7
Author: Jakub Jelinek
Date: Wed May 7 17:25:42 2025 +0200
libcpp: Further fixes for incorrect line numbers in large files [PR120061]
The backport of the PR108900 fix to 14 branch broke building chromium
because static_assert (__LINE__ == expected_line_number, ""); now triggers
as the __LINE__ values are off by one.
This isn't the case on the trunk and 15 branch because we've switched
to 64-bit location_t and so one actually needs far longer header files
to trigger it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12
contain (large) testcases in patch form which show on the 14 branch
that the first one used to fail before the PR108900 backport and now
works correctly, while the second one attempts to match the chromium
behavior and it used to pass before the PR108900 backport and now it
FAILs.
The two testcases show rare problematic cases, because
do_include_common -> parse_include -> check_eol -> check_eol_1 ->
cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start
triggers there
/* Allocate the new line_map. However, if the current map only has a
single line we can sometimes just increase its column_bits
instead. */
if (line_delta < 0
|| last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map)
|| SOURCE_COLUMN (map, highest) >= (1U << (column_bits -
range_bits))
|| ( /* We can't reuse the map if the line offset is sufficiently
large to cause overflow when computing location_t values.
*/
(to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map))
>= (((uint64_t) 1)
<< (CHAR_BIT * sizeof (linenum_type) - column_bits)))
|| range_bits < map->m_range_bits)
map = linemap_check_ordinary
(const_cast
(linemap_add (set, LC_RENAME,
ORDINARY_MAP_IN_SYSTEM_HEADER_P (map),
ORDINARY_MAP_FILE_NAME (map),
to_line)));
and so creates a new ordinary map on the line right after the
(problematic) #include line.
Now, in the spot that r14-11679-g8a884140c2bcb7 patched,
pfile->line_table->highest_location in all 3 tests (also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c13
) is before the decrement the start of the line after the #include line and
so
the decrement is really desirable in that case to put highest_location
somewhere on the line where the #include actually is.
But at the same time it is also undesirable, because if we do decrement it,
then linemap_add LC_ENTER called from _cpp_do_file_change will then
/* Generate a start_location above the current highest_location.
If possible, make the low range bits be zero. */
location_t start_location = set->highest_location + 1;
unsigned range_bits = 0;
if (start_location < LINE_MAP_MAX_LOCATION_WITH_COLS)
range_bits = set->default_range_bits;
start_location += (1 << range_bits) - 1;
start_location &= ~((1 << range_bits) - 1);
linemap_assert (!LINEMAPS_ORDINARY_USED (set)
|| (start_location
>= MAP_START_LOCATION (LINEMAPS_LAST_ORDINARY_MAP
(set;
and we can end up with the new LC_ENTER ordinary map having the same
start_location as the preceding LC_RENAME one.
Next thing that happens is computation of included_from:
if (reason == LC_ENTER)
{
if (set->depth == 0)
map->included_from = 0;
else
/* The location of the end of the just-closed map. */
map->included_from
= (((map[0].start_location - 1 - map[-1].start_location)
& ~((1 << map[-1].m_column_and_range_bits) - 1))
+ map[-1].start_location);
The normal case (e.g. with the testcase included at the start of this
comment) is
that map[-1] starts somewhere earlier and so map->included_from computation
above
nicely computes location_t which expands to the start of the #include line.
With r14-11679 reverted, for #c11 as well as #c12
map[0].start_location == map[-1].start_location above, and so it is
((location_t) -1 & ~((1 << map[-1].m_column_and_range_bits) - 1)))
+ map[-1].start_location,
which happens to be start of the #include line.
For #c11 map[0].start_location is 0x53a0 and map[-1] has
m_column_and_range_bits 7 and map[-2] has m_column_and_range_bits 12 and
[Bug target/97786] rs6000 isinf etc. are pretty horrible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97786 --- Comment #6 from Segher Boessenkool --- Hi Surya! Hrm yes, xststdcdp _does_ return a sign bit as well. Do we currently say that in RTL as well? Unfortunately we cannot just follow an xststdcdp by a setb, setb tests bit 1, but the tdp sets bit 2 only. But I'm sure whatever code we generate can be better than what we have now (mfcr? Is this compiled without any -mcpu= or something? But that cannot be true, we wouldn't get the tdc insn then either. There really should be some setbc or isel etc. insns).
[Bug tree-optimization/120032] Fails to pattern match clz from DeBruijn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120032 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug fortran/120152] [15/16 Regression] libgfortran ABI problem starting with r15-4124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120152 --- Comment #1 from Jakub Jelinek --- Created attachment 61350 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61350&action=edit gcc16-pr120152.patch So far lightly tested patch. The abilist regressions are gone with it.
[Bug libstdc++/120147] [16 Regression] libstdc++-v3 build failure for mingw32 target: src/c++23/print.cc:102:49: error: invalid conversion from 'std::basic_filebuf::native_handle_type' {aka 'int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120147 --- Comment #5 from LIU Hao --- issue seems to be that in `ac_fn_cxx_try_compile ()` there's } && test -s conftest.$ac_objext; then : which checks whether an object file is created, but the cmdline above has `-S` which produces an assembly file instead of an object file, causing the check to fail.
[Bug tree-optimization/118950] [14 regression] RISC-V: rv64gcv runtime mismatch at -O3 since r14-4038-gb975c0dc3be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950 Robin Dapp changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #15 from Robin Dapp --- Fixed.
[Bug libstdc++/120088] Use of uninitialized value in constant expression when copy-constructing a std::expected from another copy-assigned non-erroneous std::expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120088 --- Comment #3 from Jonathan Wakely --- (In reply to Jiang An from comment #2) > The divergence is probably due to that Clang and EDG haven't implemented > CWG2658 > (https://cplusplus.github.io/CWG/issues/2658.html). Yes, that would explain it, thanks.
