[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/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.
[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 Ever confirmed|0 |1 Last reconfirmed||2025-05-07 Status|UNCONFIRMED |ASSIGNED
[Bug tree-optimization/120135] Strange -Wuninitialized behavior with struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120135 --- Comment #9 from Andrew Bell --- As a note, this code doesn't evoke a warning on any other compiler/target that I tried.
[Bug c++/120161] [14/15/16 Regression] Deduction failure with nested dependent type with a class base classes of 2 of the inner type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120161 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #6 from mcccs at gmx dot com --- r14-4112-g80968d5f4683ff
[Bug gcov-profile/120086] FAIL: gcc.misc-tests/gcov-29.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #13 from Jørgen Kvalsvik ---
(In reply to John David Anglin from comment #12)
> With patch, gcov-29 now passes. But gcov-30 fails with excess errors
>
> FAIL: gcc.misc-tests/gcov-30.c (test for excess errors)
> Excess errors:
> /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.misc-tests/gcov-30.c:867:1:
> warning: target does not support atomic profile update, single mode is
> selected
Presumably there are is no atomics support on hppa64? It falls back to single
as it should. Does it pass when combining with your {
dg-require-effective-target profile_update_atomic } patch?
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051
--- Comment #5 from Christoph Reiter ---
Thanks for working on this.
I applied the gcc patch and can confirm that the original example no longer
crashes. I found another crasher though and reduced it to:
$ cat test.c
// gcc -O1 -gcodeview -c test2.c
typedef union a b;
int c(b *) {}
$ gcc -O1 -gcodeview -c test2.c
test2.c:3:1: internal compiler error: Segmentation fault
3 | int c(b *) {}
| ^~~
[Bug cobol/119769] FE: GnuCOBOL extension BINARY-C-LONG missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119769 Simon Sobisch changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED |--- --- Comment #2 from Simon Sobisch --- I agree that this provides a good fix in general and something that may be useful to fix this bug - but this bug is still open: * if "-dialect gnu" is used, then there should be no additional line needed * at least if the gcobc wrapper script is used, that should not be necessary (I'd prefer that to be implemented via -dialect, not via a hack that uses --include binary-c-long.cpy with the code suggested) * the suggested workaround only works correctly for 64bit gcc environments, in 32bit it would equate to BINARY-LONG (not sure if conditional compilation works again in gcobol and I haven't checked its manpage for implicit defined compiler constants that can be used to check for 32bit OS which may be used here)
[Bug c++/120155] ICE when lambda return type is the decltype of statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120155 --- Comment #1 from Andrew Pinski --- : In function 'void fun()': :6:17: internal compiler error: tree check: expected tree that contains 'decl with visibility' structure, have 'parm_decl' in start_decl, at cp/decl.cc:6037 6 | int a = t; | ^ Is the ICE with checking.
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #6 from Sam James --- Mark, when you get a chance to work on this, if you haven't tried it before, I'd recommend doing a bootstrap w/ -gcodeview enabled by default to see what falls out.
[Bug c++/120155] ICE with generic lambda return type is the decltype of statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120155 Andrew Pinski changed: What|Removed |Added Summary|ICE when generic lambda |ICE with generic lambda |return type is the decltype |return type is the decltype |of statement expression |of statement expression --- Comment #2 from Andrew Pinski --- > but all published versions do not. that is just a checking ICE ... GCC 10.3.0 with --enable-checking=yes provides the same ICE as the trunk.
[Bug c++/120155] ICE with generic lambda return type with a decltype of statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120155 --- Comment #3 from Andrew Pinski --- Without using a generic lambda (auto), GCC gives this error message: ``` : In function 'void fun()': :6:17: error: ISO C++ forbids in-class initialization of non-const static member 'fun()a' 6 | int a = 1; | ^ ```
[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 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #4 from mcccs at gmx dot com --- r9-4045-g0c1e0d63fe0cea found when bisecting the reduced testcase with -std=c++2a -Wall
[Bug c++/101533] [12/13 Regression] ICE in gen_type_die_with_usage, at dwarf2out.c:25988
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101533 --- Comment #13 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:e6652764a4558fe9487f17e6c7b18fbc577e8df7 commit r13-9641-ge6652764a4558fe9487f17e6c7b18fbc577e8df7 Author: Richard Biener Date: Wed Mar 5 14:24:50 2025 +0100 debug/101533 - ICE with variant typedef DIE generation There's a sanity check in gen_type_die_with_usage that trips unnecessarily for a case where the relevant DIE has already been generated successfully in other ways. The following keys the existing TREE_ASM_WRITTEN check on the correct object, honoring this and does nothing instead of ICEing for the testcase at hand. PR debug/101533 * dwarf2out.cc (gen_type_die_with_usage): When we have output the typedef already do nothing for a typedef variant. Do not set TREE_ASM_WRITTEN on the type. * g++.dg/debug/pr101533.C: New testcase. (cherry picked from commit 99a3f013c3bb8bc022ca488b40aa18fd97b5224d)
[Bug c/101478] [12/13 Regression] ICE with statement expression and offsetof like expression since r10-7127-gcb99630f254aae
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101478 --- Comment #10 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:068aa9a7a9cc163ee5f31bffd746a8cd2ebfef7e commit r13-9640-g068aa9a7a9cc163ee5f31bffd746a8cd2ebfef7e Author: Richard Biener Date: Wed Jul 31 10:07:45 2024 +0200 middle-end/101478 - ICE with degenerate address during gimplification When we gimplify &MEM[0B + 4] we are re-folding the address in case types are not canonical which ends up with a constant address that recompute_tree_invariant_for_addr_expr ICEs on. Properly guard that call. PR middle-end/101478 * gimplify.cc (gimplify_addr_expr): Check we still have an ADDR_EXPR before calling recompute_tree_invariant_for_addr_expr. * gcc.dg/pr101478.c: New testcase. (cherry picked from commit 33ead6400ad59d4b38fa0527a9a7b53a28114ab7)
[Bug c++/120130] Cannot declare function template as friend in the presence of same named member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120130
--- Comment #3 from Fedor Chelnokov ---
This slightly modified program:
```
template
class Foo;
template
int g(const Foo&);
template
class Foo {
public:
template
int g(const Foo&) = delete;
friend int g<>(const Foo&);
private:
int m = 1;
};
template
int g(const Foo& f) { return f.m; }
int main() {
return g(Foo{});
}
```
is accepted by both Clang and MSVC (but not EDG and GCC). Online demo:
https://gcc.godbolt.org/z/M3cWEc679
[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 #6 from LIU Hao --- (In reply to Jonathan Wakely from comment #3) > And yet somehow it does. Confirmed. You forgot to restore the old `CXXFLAGS`.
[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 Richard Biener changed: What|Removed |Added Version|15.0|16.0 Target Milestone|--- |16.0
[Bug libstdc++/120159] New: is_layout_compatible_v not exported in std module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120159
Bug ID: 120159
Summary: is_layout_compatible_v not exported in std module
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alberto.gcc.bugzilla at gmail dot com
Target Milestone: ---
Hello
It appears that is_layout_compatible_v, is_corresponding_member_v, and
is_pointer_interconvertible_with_class_v aren't exported by the std module.
In std.cc.in I can only find:
#if __cpp_lib_is_layout_compatible
using std::is_corresponding_member;
using std::is_layout_compatible;
#endif
#if __cpp_lib_is_pointer_interconvertible
using std::is_pointer_interconvertible_base_of;
using std::is_pointer_interconvertible_base_of_v;
using std::is_pointer_interconvertible_with_class;
#endif
As a consequence, the following program:
``` hello.cpp
import std;
struct A
{
double a;
};
struct B
{
double a;
};
static_assert(std::is_layout_compatible_v);
static_assert(std::is_layout_compatible::value); // passes
```
compiled with:
g++ -std=c++23 -fmodules -fsearch-include-path bits/std.cc hello.cpp -o
hello.out
fails:
hello.cpp:13:20: error: 'is_layout_compatible_v' is not a member of 'std'
13 | static_assert(std::is_layout_compatible_v);
|^~
Thank you
[Bug libstdc++/120160] New: Implicitly import std if stadard library header is included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120160 Bug ID: 120160 Summary: Implicitly import std if stadard library header is included Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: antoshkka at gmail dot com Target Milestone: --- Please add a preprocessor macro that replaces content of the header with `import std;` if the macro is defined by user. For example libstdc++-v3/include/std/vector can be changed in the following way: #ifndef _GLIBCXX_VECTOR #define _GLIBCXX_VECTOR 1 #if defined(GLIBCXX_IMPLICIT_MODULES_USE) import std; #else #ifdef _GLIBCXX_SYSHDR #pragma GCC system_header #endif ... // all the remaining code from #endif /* GLIBCXX_IMPLICIT_MODULES_USE */ #endif /* _GLIBCXX_VECTOR */ Motivation: 1. Implicit `import std;` in standard library header would improve compile times if module std is available. 2. Migration from includes to `import std;` for big projects is not trivial. The above approach eases that migration
[Bug target/97786] rs6000 isinf etc. are pretty horrible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97786
--- Comment #5 from Surya Kumari Jangala ---
The input gimple to RTL has the builtin split into two parts: ‘isinfD’ and
‘signbitD’ due to which in the final assembly generated, we have instructions
to check the sign bit of the floating point number instead of using the sign
bit computed by the xststdcdp insn.
Instead, if we can avoid splitting the builtin, we can modify RTL to handle the
builtin and generate optimized instructions.
This split seems to be happening before the gimple passes. Using
-fdump-tree-all-all option, the first file in the dump
(.006t.original) has the split:
;; Function test1 (null)
;; enabled by -tree-original
{
return isinfD.1825 (xD.3943) != 0 ? signbitD.1014 (xD.3943) != 0 ? -1 : 1 :
0;
}
[Bug c++/119864] [15/16 Regression][modules] ICE with -fmodules and omp reduction of UDT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119864
Alberto changed:
What|Removed |Added
CC||alberto.gcc.bugzilla@gmail.
||com
--- Comment #6 from Alberto ---
Hello
This issue also affects the std module as it has "declare reduction" clauses to
support the unseq execution policy.
For example, the program:
``` hello.cpp
import std;
int main()
{
std::vector v;
}
```
compiled with:
g++ -std=c++23 -fmodules -fopenmp-simd -fsearch-include-path bits/std.cc
hello.cpp -o hello.out
causes g++ to crash:
hello.cpp: In function 'void omp declare reduction __min_func(_ComplexType&)':
hello.cpp:5:8: internal compiler error: Segmentation fault
5 | std::vector v;
|^~
0x2287465 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x22989b6 internal_error(char const*, ...)
???:0
0xfd2b06 relayout_decl(tree_node*)
???:0
0xc740ee allocate_struct_function(tree_node*, bool)
???:0
0x9011e1 module_state::read_cluster(unsigned int)
???:0
0x901a7d module_state::load_section(unsigned int, binding_slot*)
???:0
0x901b28 module_state::lazy_load(unsigned int, binding_slot*)
???:0
0x900fc3 module_state::read_cluster(unsigned int)
???:0
0x901a7d module_state::load_section(unsigned int, binding_slot*)
???:0
0x901b28 module_state::lazy_load(unsigned int, binding_slot*)
???:0
0x900fc3 module_state::read_cluster(unsigned int)
???:0
0x901a7d module_state::load_section(unsigned int, binding_slot*)
???:0
0x901c30 lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*)
???:0
0x91479e name_lookup::search_namespace_only(tree_node*)
???:0
0x914998 name_lookup::search_namespace(tree_node*)
???:0
0x914ae7 name_lookup::search_qualified(tree_node*, bool)
???:0
0x9180a7 lookup_qualified_name(tree_node*, tree_node*, LOOK_want, bool)
???:0
0x981ebd c_parse_file()
???:0
0xa8b739 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/120012] [12/13/14/15/16 Regression] P1008R1 causes tail padding reuse in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120012 --- Comment #6 from GCC Commits --- The releases/gcc-15 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:809c5d7486f91d59e798e0c70ac887f837039ece commit r15-9635-g809c5d7486f91d59e798e0c70ac887f837039ece Author: Jason Merrill Date: Wed Apr 30 10:18:46 2025 -0400 c++: C++17/20 class layout divergence [PR120012] C++20 made a class with only explicitly defaulted constructors no longer aggregate, and this wrongly affected whether the class is considered "POD for layout purposes" under the ABI. Conveniently, we already have check_non_pod_aggregate to diagnose cases where this makes a difference, due to PR103681 around a C++14 aggregate change. This backport is the same code change as the trunk version, but since -fabi-version=21 cannot be selected, the fix is not available, only the warning, so the first testcase is different. PR c++/120012 gcc/cp/ChangeLog: * cp-tree.h (struct lang_type): Add non_aggregate_pod. (CLASSTYPE_NON_AGGREGATE_POD): New. * class.cc (check_bases_and_members): Set it. (check_non_pod_aggregate): Diagnose it. gcc/testsuite/ChangeLog: * g++.dg/abi/base-defaulted1.C: New test. * g++.dg/abi/base-defaulted1a.C: New test. (cherry picked from commit e6e3b0772ed40cc65a544bbe744ece62d8b9713e)
[Bug cobol/119769] FE: GnuCOBOL extension BINARY-C-LONG missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119769 James K. Lowden changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from James K. Lowden --- Thank you for this PR. It has been fixed as follows: commit be83dcb7ec7da087e7fb3493d200f87f3c7ba8e6 (HEAD -> parser) Author: James K. Lowden Date: Wed May 7 11:42:25 2025 -0400 As of that commit, the above program compiles if this is the first line: >>COBOL-WORDS SUBSTITUTE BINARY-DOUBLE BY BINARY-C-LONG or >>COBOL-WORDS equate BINARY-DOUBLE with BINARY-C-LONG depending on whether the meaning of BINARY-DOUBLE should be preserved. In general, it should be possible in gcobol to replace any ISO keyword with an alias. Failure to do so is considered a bug.
[Bug libstdc++/120159] is_layout_compatible_v not exported in std module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120159 --- Comment #1 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8a1f3615c01cdbf5b2d37448c8bb09a96d5e3330 commit r16-451-g8a1f3615c01cdbf5b2d37448c8bb09a96d5e3330 Author: Jonathan Wakely Date: Wed May 7 17:06:11 2025 +0100 libstdc++: Add missing export for std::is_layout_compatible_v [PR120159] libstdc++-v3/ChangeLog: PR libstdc++/120159 * src/c++23/std.cc.in (is_layout_compatible_v): Export.
[Bug libstdc++/120114] Format width is not correctly handled for chrono formatting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120114 Tomasz Kamiński changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tomasz Kamiński --- Fixed for 15.2 and 16.
[Bug libstdc++/120114] Format width is not correctly handled for chrono formatting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120114 --- Comment #2 from GCC Commits --- The releases/gcc-15 branch has been updated by Tomasz Kaminski : https://gcc.gnu.org/g:e52f71b6dd888f0d5548d9f5bd139601dbafb3be commit r15-9631-ge52f71b6dd888f0d5548d9f5bd139601dbafb3be 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 (cherry picked from commit 52f6ab55051ff43fd1b40ff06d9501043f8ba844)
[Bug libstdc++/107761] Implement C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:a33b5db97c4e87bd02f1af1a75b2d84376442fa0
commit r16-442-ga33b5db97c4e87bd02f1af1a75b2d84376442fa0
Author: Luc Grosheintz
Date: Tue Apr 29 14:46:09 2025 +0200
libstdc++: Implement std::extents [PR107761].
This implements std::extents from according to N4950 and
contains partial progress towards PR107761.
If an extent changes its type, there's a precondition in the standard,
that the value is representable in the target integer type. This
precondition is not checked at runtime.
The precondition for 'extents::{static_,}extent' is that '__r < rank()'.
For extents this precondition is always violated and results in
calling __builtin_trap. For all other specializations it's checked via
__glibcxx_assert.
PR libstdc++/107761
libstdc++-v3/ChangeLog:
* include/std/mdspan (extents): New class.
* src/c++23/std.cc.in: Add 'using std::extents'.
Signed-off-by: Luc Grosheintz
[Bug tree-optimization/120032] Fails to pattern match clz from DeBruijn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120032
--- Comment #3 from Richard Biener ---
And to avoid repeated scanning of DECL_INITIAL when we add more of these
patterns we could record classification of the table in a custom
internal decl attribute we add, __attribute__(("table kind"(int)))
with an enum also recording "unknown" so we scan at most once.
[Bug libfortran/120153] Missing UINTEGER symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120153 --- Comment #1 from Jakub Jelinek --- Created attachment 61351 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61351&action=edit gcc16-pr120153.patch Untested fix.
[Bug middle-end/111125] [14 Regression] tree-ssa.exp and vect.exp failures after commit r14-3281-g99b5921bfc8f91
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25 --- Comment #9 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:337d3cdfa8bb8b8404d62ea45690095f9b566cbb commit r13-9635-g337d3cdfa8bb8b8404d62ea45690095f9b566cbb Author: Richard Biener Date: Thu Aug 24 11:10:43 2023 +0200 tree-optimization/25 - avoid BB vectorization in novector loops When a loop is marked with #pragma GCC novector the following makes sure to also skip BB vectorization for contained blocks. That avoids gcc.dg/vect/bb-slp-29.c failing on aarch64 because of extra BB vectorization therein. I'm not specifically dealing with sub-loops of novector loops, the desired semantics isn't documented. PR tree-optimization/25 * tree-vect-slp.cc (vect_slp_function): Split at novector loop entry, do not push blocks in novector loops. (cherry picked from commit 43da77a4f1636280c4259402c9c2c543e6ec6c0b)
[Bug c++/79786] [12/13 Regression] ICE tree check: expected class 'type', have 'declaration' (var_decl) in iamcu_alignment, at config/i386/i386.c:30263
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79786 --- Comment #13 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:c0e3078580f4834e4d3d1ba517016a0220b4e3b6 commit r13-9637-gc0e3078580f4834e4d3d1ba517016a0220b4e3b6 Author: Richard Biener Date: Mon Feb 3 11:27:20 2025 +0100 c++/79786 - bougs invocation of DATA_ABI_ALIGNMENT macro The first argument is supposed to be a type, not a decl. PR c++/79786 gcc/cp/ * rtti.cc (emit_tinfo_decl): Fix DATA_ABI_ALIGNMENT invocation. (cherry picked from commit 6ec19825b4e72611cdbd4749feed67b61392aa81)
[Bug middle-end/87984] [12/13 Regression] wrong code for local reg var input to asm inside a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984 --- Comment #48 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:f2d0fb238b1a6eab85924515f0c1ffc2f939e6a7 commit r13-9638-gf2d0fb238b1a6eab85924515f0c1ffc2f939e6a7 Author: Richard Biener Date: Fri Feb 28 10:36:11 2025 +0100 tree-optimization/87984 - hard register assignments not preserved The following disables redundant store elimination to hard register variables which isn't valid. PR tree-optimization/87984 * tree-ssa-dom.cc (dom_opt_dom_walker::optimize_stmt): Do not perform redundant store elimination to hard register variables. * tree-ssa-sccvn.cc (eliminate_dom_walker::eliminate_stmt): Likewise. * gcc.target/i386/pr87984.c: New testcase. (cherry picked from commit 535115caaf97f5201fb528f67f15b4c52be5619d)
[Bug lto/91299] [12/13 Regression] LTO inlines a weak definition in presence of a non-weak definition from an ELF file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91299 --- Comment #23 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:da579a833cf5a5ae463be3f4da70df782612a800 commit r13-9639-gda579a833cf5a5ae463be3f4da70df782612a800 Author: Richard Biener Date: Fri Feb 28 14:09:29 2025 +0100 lto/91299 - weak definition inlined with LTO The following fixes a thinko in the handling of interposed weak definitions which confused the interposition check in get_availability by setting DECL_EXTERNAL too early. PR lto/91299 gcc/lto/ * lto-symtab.cc (lto_symtab_merge_symbols): Set DECL_EXTERNAL only after calling get_availability. gcc/testsuite/ * gcc.dg/lto/pr91299_0.c: New testcase. * gcc.dg/lto/pr91299_1.c: Likewise. (cherry picked from commit bc34db5b12e008f6ec4fdf4ebd22263c8617e5e3)
[Bug gcov-profile/120086] FAIL: gcc.misc-tests/gcov-29.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086 --- Comment #12 from John David Anglin --- With patch, gcov-29 now passes. But gcov-30 fails with excess errors FAIL: gcc.misc-tests/gcov-30.c (test for excess errors) Excess errors: /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.misc-tests/gcov-30.c:867:1: warning: target does not support atomic profile update, single mode is selected and gcov-pr86536.c fails spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/gcov -b gcov-pr86536.c File '/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.misc-tests/gcov-pr86536.c' Lines executed:40.00% of 5 No branches Calls executed:0.00% of 1 Creating 'gcov-pr86536.c.gcov' Lines executed:40.00% of 5 FAIL: gcc.misc-tests/gcov-pr86536.c line 15: is #:should be 1 FAIL: gcc.misc-tests/gcov-pr86536.c line 18: is #:should be 1 FAIL: gcc.misc-tests/gcov-pr86536.c line 21: is 1:should be 2 FAIL: gcc.misc-tests/gcov-pr86536.c line 22: is 1:should be 2 FAIL: gcc.misc-tests/gcov-pr86536.c line 19: expected return percentages not found: 200 FAIL: gcc.misc-tests/gcov-pr86536.c gcov: 4 failures in line counts, 0 in branch percentages, 0 in condition/decision, 0 in prime-paths, 1 in return percentages, 0 in intermediate format, 0 failed in filters The gcov-pr86536.c fails appear to be new.
[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 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-05-07 Status|UNCONFIRMED |NEW --- Comment #5 from Andrew Pinski --- .
[Bug libstdc++/120159] is_layout_compatible_v not exported in std module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120159 --- Comment #3 from GCC Commits --- The releases/gcc-15 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d0e6d797b35ae89044f967160d4abe3868190f0f commit r15-9636-gd0e6d797b35ae89044f967160d4abe3868190f0f Author: Jonathan Wakely Date: Wed May 7 17:06:11 2025 +0100 libstdc++: Add missing export for std::is_layout_compatible_v [PR120159] libstdc++-v3/ChangeLog: PR libstdc++/120159 * src/c++23/std.cc.in (is_layout_compatible_v): Export. (cherry picked from commit 8a1f3615c01cdbf5b2d37448c8bb09a96d5e3330)
[Bug libfortran/120152] [15/16 Regression] libgfortran ABI problem starting with r15-4124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120152 --- Comment #2 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:41c8e9b61defb6c616bf35ac9693a52f848afca3 commit r16-452-g41c8e9b61defb6c616bf35ac9693a52f848afca3 Author: Jakub Jelinek Date: Wed May 7 18:46:51 2025 +0200 ibfortran: Readd 15 accidentally removed libgfortran symbols [PR120152] The r15-4124-gc0002a675a92e76d change seems to have accidentally dropped 5 sourcefiles from i_maxloc1_c, which resulted in dropping 15 GFORTRAN_8 symbols on x86_64 and 6 on i686. The following patch adds it back, so that we export those symbols again, fixing the ABI problem. 2025-05-07 Jakub Jelinek PR libfortran/120152 * Makefile.am (i_maxloc1_c): Readd generated/maxloc1_4_i8.c, generated/maxloc1_8_i8.c, generated/maxloc1_16_i8.c, generated/maxloc1_4_i16.c, generated/maxloc1_8_i16.c. Move generated/maxloc1_16_i16.c entry earlier in the list. * Makefile.in: Regenerated.
[Bug target/120162] Prefetch causes vectorization to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120162 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target||x86_64 Component|c |target --- Comment #3 from Andrew Pinski --- This is both a target issue, _mm_prefetch does not get folded into __builtin_prefetch and a vectorizer issue. I will split out the vectorizer issue from the target side of things in a few min utes. This is will stay the target issue.
[Bug c++/120161] [14/15/16 Regression] Deduction failure with nested dependent type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120161 Andrew Pinski changed: What|Removed |Added Attachment #61356|0 |1 is obsolete|| Attachment #61357|0 |1 is obsolete|| --- Comment #3 from Andrew Pinski --- Created attachment 61358 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61358&action=edit C++98 testcase
[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 #12 from Andrew Pinski --- (In reply to Filip Kastl from comment #10) > 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. Well before switch lowering you won't have an empty switch, but ... Take: ``` : switch (b.0_1) [0.00%], case 5: [100.00%], case 101: [100.00%]> ;;succ: 5 [never] count:0 (precise, freq 0.) (EXECUTABLE) ;;4 [always] count:0 (precise, freq 0.) (EXECUTABLE) ;; basic block 4, loop depth 0, count 0 (precise, freq 0.), probably never executed ;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED) ;;pred: 3 [always] count:0 (precise, freq 0.) (EXECUTABLE) : __builtin_unreachableD.2065 (); ;;succ: ``` And switch lowering removes the unreachable block and the 2 case statements (5/101). So we end up with just a default. And then the assert happens.
[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796 --- Comment #15 from GCC Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:0a339746e7646bacf2c8aa5512268d23660f26f9 commit r16-454-g0a339746e7646bacf2c8aa5512268d23660f26f9 Author: Richard Earnshaw Date: Fri Mar 28 12:59:03 2025 + arm: Only reverse FP inequalities when -ffinite-math-only [PR110796...] On Arm we have been failing to fully implement support for IEEE NaNs in inequality comparisons because we have allowed reversing of inequalities in a way that allows SELECT_CC_MODE to produce different answers. For example, the reverse of GT is UNLE, but if we pass these two RTL codes to SELECT_CC_MODE, the former will return CCFPEmode, while the latter CCFPmode. It would be possible to allow fully reversible FPmodes, but to do so would involve adding yet more RTL codes, something like NOT_GT and NOT_UNLE, for the cases we cannot currently reverse. NOT_GT would then have the same condition code generation as UNLT, but the same mode selection as GT. In the mean time, we need to restrict REVERSIBLE_CC_MODE to non-floating modes unless we are compiling with -ffinite-math-only. In that case we can continue to reverse the comparisons, but now we want to always select CCFPmode as there's no need to consider the exception raising cases. PR target/110796 PR target/118446 gcc/ChangeLog: * config/arm/arm.h (REVERSIBLE_CC_MODE): FP modes are only reversible if flag_finite_math_only. * config/arm/arm.cc (arm_select_cc_mode): Return CCFPmode for all FP comparisons if flag_finite_math_only. gcc/testsuite/ChangeLog: * gcc.target/arm/armv8_2-fp16-arith-1.c: Adjust due to no-longer emitting VCMPE when -ffast-math..
