[Bug target/120228] Need to call df_insn_rescan after emit_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120228 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Richard Biener --- Fixed.
[Bug tree-optimization/120219] [16 Regression] ~11% slowdown of 548.exchange2_r on x86_64 (maybe also on aarch64?) since r16-448-g8335fd561fa823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120219 Filip Kastl changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=120226 Summary|[16 Regression] ~11%|[16 Regression] ~11% |slowdown of 548.exchange2_r |slowdown of 548.exchange2_r |on x86_64 |on x86_64 (maybe also on ||aarch64?) since ||r16-448-g8335fd561fa823 --- Comment #3 from Filip Kastl --- pr120226 is the same thing as this pr. There's some brief discussion over there but I'll close it so that we don't have two PRs for the same bug. One of the things mentioned there is a slowdown on aarch64 which might be the same slowdown as on x86_64. So this might not be x86_64-specific. Which is interesting since pr119919 was x86_64 specific, I believe. -O2 -march=generic -flto Ampere Altra Neoverse N1: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=581.407.0
[Bug target/120226] 8% regression of exchange2 with -O2 between g:d0571638a6bad932 and g:9b13bea07706a7ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120226 Filip Kastl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||pheeck at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Filip Kastl --- This is the same bug as pr120219 so let's move the discussion there. *** This bug has been marked as a duplicate of bug 120219 ***
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 120226, which changed state. Bug 120226 Summary: 8% regression of exchange2 with -O2 between g:d0571638a6bad932 and g:9b13bea07706a7ca https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120226 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/120219] [16 Regression] ~11% slowdown of 548.exchange2_r on x86_64 (maybe also on aarch64?) since r16-448-g8335fd561fa823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120219 --- Comment #4 from Filip Kastl --- *** Bug 120226 has been marked as a duplicate of this bug. ***
[Bug libstdc++/119667] libstdc++ configure checks for libbacktrace need atomics for void* and size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119667
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:4589ccbed5cad42296d4d1810b61e8dec0dadf79
commit r16-540-g4589ccbed5cad42296d4d1810b61e8dec0dadf79
Author: Thomas Schwinge
Date: Mon May 12 10:35:11 2025 +0200
libstdc++: Rewrite atomic builtin checks: Fix up 'GLIBCXX_ENABLE_BACKTRACE'
check with 'size_t' [PR119667]
Fix-up for commit 86627faec10da53d7532805019e5296fcf15ac09
"libstdc++: Rewrite atomic builtin checks [PR70560]", which, for example,
for
x86_64-pc-linux-gnu lost '-DHAVE_ATOMIC_FUNCTIONS=1' from
'BACKTRACE_CPPFLAGS'
due to:
configure:53554: checking for atomic builtins for libbacktrace
configure:53587: [...]/./gcc/xgcc -shared-libgcc -B[...]/./gcc
-nostdinc++ -L[...]/x86_64-pc-linux-gnu/libstdc++-v3/src
-L[...]/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L[...]/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/x86_64-pc-linux-gnu/bin/ -B/x86_64-pc-linux-gnu/lib/ -isystem
/x86_64-pc-linux-gnu/include -isystem /x86_64-pc-linux-gnu/sys-include-o
conftest -O0 conftest.cpp >&5
conftest.cpp: In function 'int main()':
conftest.cpp:265:13: error: 'size_t' was not declared in this scope
265 | size_t s = 0;
| ^~
conftest.cpp:1:1: note: 'size_t' is defined in header ''; this
is probably fixable by adding '#include '
1 | /* confdefs.h */
conftest.cpp:273:31: error: 's' was not declared in this scope
273 | __atomic_store_n(&s, s, __ATOMIC_RELEASE);
| ^
configure:53587: $? = 1
configure: failed program was:
| /* confdefs.h */
[...]
| int
| main ()
| {
|[...]
| size_t s = 0;
|[...]
| // backtrace_atomic_store_size_t
| __atomic_store_n(&s, s, __ATOMIC_RELEASE);
|[...]
| }
configure:53595: result: no
PR libstdc++/70560
PR libstdc++/119667
libstdc++-v3/
* acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Use '__SIZE_TYPE__'
instead of 'size_t'.
* configure: Regenerate.
[Bug libstdc++/70560] Review configure checks for _GLIBCXX_ATOMIC_BUILTINS and atomicity_dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560
--- Comment #11 from GCC Commits ---
The trunk branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:4589ccbed5cad42296d4d1810b61e8dec0dadf79
commit r16-540-g4589ccbed5cad42296d4d1810b61e8dec0dadf79
Author: Thomas Schwinge
Date: Mon May 12 10:35:11 2025 +0200
libstdc++: Rewrite atomic builtin checks: Fix up 'GLIBCXX_ENABLE_BACKTRACE'
check with 'size_t' [PR119667]
Fix-up for commit 86627faec10da53d7532805019e5296fcf15ac09
"libstdc++: Rewrite atomic builtin checks [PR70560]", which, for example,
for
x86_64-pc-linux-gnu lost '-DHAVE_ATOMIC_FUNCTIONS=1' from
'BACKTRACE_CPPFLAGS'
due to:
configure:53554: checking for atomic builtins for libbacktrace
configure:53587: [...]/./gcc/xgcc -shared-libgcc -B[...]/./gcc
-nostdinc++ -L[...]/x86_64-pc-linux-gnu/libstdc++-v3/src
-L[...]/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L[...]/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/x86_64-pc-linux-gnu/bin/ -B/x86_64-pc-linux-gnu/lib/ -isystem
/x86_64-pc-linux-gnu/include -isystem /x86_64-pc-linux-gnu/sys-include-o
conftest -O0 conftest.cpp >&5
conftest.cpp: In function 'int main()':
conftest.cpp:265:13: error: 'size_t' was not declared in this scope
265 | size_t s = 0;
| ^~
conftest.cpp:1:1: note: 'size_t' is defined in header ''; this
is probably fixable by adding '#include '
1 | /* confdefs.h */
conftest.cpp:273:31: error: 's' was not declared in this scope
273 | __atomic_store_n(&s, s, __ATOMIC_RELEASE);
| ^
configure:53587: $? = 1
configure: failed program was:
| /* confdefs.h */
[...]
| int
| main ()
| {
|[...]
| size_t s = 0;
|[...]
| // backtrace_atomic_store_size_t
| __atomic_store_n(&s, s, __ATOMIC_RELEASE);
|[...]
| }
configure:53595: result: no
PR libstdc++/70560
PR libstdc++/119667
libstdc++-v3/
* acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Use '__SIZE_TYPE__'
instead of 'size_t'.
* configure: Regenerate.
[Bug libstdc++/120170] [meta-bug] C++ std::locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120170 Bug 120170 depends on bug 65909, which changed state. Bug 65909 Summary: check_v3_target_namedlocale blows up on targets that don't support command-line arguments https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65909 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/120221] Missed optimization related to switch handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120221 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|2025-05-11 00:00:00 |2025-05-12 CC||pheeck at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #6 from Richard Biener --- So [local count: 1073741816]: _1 = (long unsigned int) val_5(D); _2 = _1 >> 3; _3 = _2 & 3; if (_3 == 0) goto ; [33.33%] else goto ; [66.67%] [local count: 715827875]: if (_3 == 2) could be transformed to _1 = (long unsigned int) val_5(D); _2 = _1; _3 = _2 & (3 << 3); if (_3 == 0 << 3) goto ; [33.33%] else goto ; [66.67%] [local count: 715827875]: if (_3 == 2 << 3) for a case where we only check a right-shifted value without AND we'd have to add a AND operation masking out the shifted bits to elide the shift. Extra care has to be taken when the tested value can be negative, the shift can duplicate the sign bit into the set of relevant bits (depending on shift amount and the existing AND mask this can or can not be disregarded).
[Bug tree-optimization/120222] [16 Regression] FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "vectorized 1 loops" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120222 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2025-05-12 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Also fails on x86 with -m32. gcc.dg/tree-ssa/gen-vect-28.c:37:10: optimized: Inlined main_1/16 into main/14 which now has time 1393.000294 and size 19, net change of +13. I'll fixup the testcase. It's odd that we now want to inline this into the "cold" main() function?
[Bug tree-optimization/120222] [16 Regression] FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "vectorized 1 loops" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120222 --- Comment #2 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e64e894006eb4d82e0a80a386cf1d1714498e161 commit r16-536-ge64e894006eb4d82e0a80a386cf1d1714498e161 Author: Richard Biener Date: Mon May 12 09:14:39 2025 +0200 testsuite/120222 - adjust gcc.dg/tree-ssa/gen-vect-28.c for inlining change We now inline main_1, confusing the expected number of vectorizations. PR testsuite/120222 * gcc.dg/tree-ssa/gen-vect-28.c: Use noipa on main_1.
[Bug libstdc++/65909] check_v3_target_namedlocale blows up on targets that don't support command-line arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65909 --- Comment #6 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3e2b83faeb6b14254641933525e63171e89d973f commit r16-537-g3e2b83faeb6b14254641933525e63171e89d973f Author: Jonathan Wakely Date: Thu May 8 09:57:28 2025 +0100 libstdc++: Make dg-require-namedlocale work for more targets [PR65909] As noted in the PR, some embedded targets do not support command-line arguments, which means that the dg-require-namedlocale check always fails. Use Sandra's suggestion of hardcoding the argument into the executable instead of passing it as a command-line argument. Realistically, those embedded targets probably don't support the named locales anyway, but at least now the tests will be UNSUPPORTED for the right reason. libstdc++-v3/ChangeLog: PR libstdc++/65909 * testsuite/lib/libstdc++.exp (check_v3_target_namedlocale): Hardcode the locale name instead of passing it to the executable. Do not hardcode buffer size for string. Reviewed-by: Tomasz KamiÅski
[Bug libstdc++/118260] Automatically add some 'skip's from gdb helper code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118260
--- Comment #15 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:31cbac3037b7811bd0df63f4a09aa981b250c4bf
commit r16-539-g31cbac3037b7811bd0df63f4a09aa981b250c4bf
Author: Jonathan Wakely
Date: Fri May 9 11:39:39 2025 +0100
libstdc++: Suppress GDB output from new 'skip' commands [PR118260]
I added some gdb.execute('skip -rfu ...') commands to the Python hook
loaded with libstdc++.so but this makes GDB print output like:
Function(s) ^std::(move|forward|as_const|(__)?addressof) will be skipped
when stepping.
This probably aren't interesting to users, so this change suppresses
that output by capturing the output into the gdb.execute return value
(which is then ignored). An exception is thrown if the gdb.execute
command fails, so this doesn't suppress any errors which might be
meaningful to users or libstdc++ developers.
libstdc++-v3/ChangeLog:
PR libstdc++/118260
* python/hook.in: Suppress output from gdb.execute calls to
register skips.
Reviewed-by: Tomasz KamiÅski
[Bug tree-optimization/120219] [16 Regression] ~11% slowdown of 548.exchange2_r on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120219 Filip Kastl changed: What|Removed |Added Summary|[16 Regression] ~11%|[16 Regression] ~11% |slowdown of 548.exchange2_r |slowdown of 548.exchange2_r |on AMD Zen |on x86_64 --- Comment #2 from Filip Kastl --- (In reply to Richard Biener from comment #1) > There was a similar jump before, so maybe we're just hitting that very thing > again? Has that been filed/bisected? That's pr119919. Could be the same thing. pr119919 is caused by one of Honza's recent vectorizer costing commits. As far as I understand, Andrew's commit doesn't touch vectorizer directly, but I guess that loop optimizations and the vectorizer are related. Btw, I've just noticed that this slowdown also happened on Intel: -O2 -march=generic -flto Intel Ice Lake (3rd generation Xeon) https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=800.407.0
[Bug debug/120227] Incorrect debug info generation with options -gcodeview -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120227 --- Comment #1 from Iouri Kharon --- FYI: The problem is in the compiler (cc1/cc1plus)- with such a combination of keys, a "mixture" of codeview-style and dwarf-style info gets into the generated assembler
[Bug libstdc++/118260] Automatically add some 'skip's from gdb helper code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118260
--- Comment #16 from GCC Commits ---
The releases/gcc-15 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:a341d96add049e1ebc94e7350ff59e82b03043d2
commit r15-9658-ga341d96add049e1ebc94e7350ff59e82b03043d2
Author: Jonathan Wakely
Date: Fri May 9 11:39:39 2025 +0100
libstdc++: Suppress GDB output from new 'skip' commands [PR118260]
I added some gdb.execute('skip -rfu ...') commands to the Python hook
loaded with libstdc++.so but this makes GDB print output like:
Function(s) ^std::(move|forward|as_const|(__)?addressof) will be skipped
when stepping.
This probably aren't interesting to users, so this change suppresses
that output by capturing the output into the gdb.execute return value
(which is then ignored). An exception is thrown if the gdb.execute
command fails, so this doesn't suppress any errors which might be
meaningful to users or libstdc++ developers.
libstdc++-v3/ChangeLog:
PR libstdc++/118260
* python/hook.in: Suppress output from gdb.execute calls to
register skips.
Reviewed-by: Tomasz KamiÅski
(cherry picked from commit 31cbac3037b7811bd0df63f4a09aa981b250c4bf)
[Bug libstdc++/65909] check_v3_target_namedlocale blows up on targets that don't support command-line arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65909 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |16.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jonathan Wakely --- Fixed for gcc-16 as Sandra suggested (ten years ago!)
[Bug tree-optimization/120231] New: GCC fails to notice that (double)u64 is non-negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231
Bug ID: 120231
Summary: GCC fails to notice that (double)u64 is non-negative
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
For the following function:
_Bool f(unsigned long u64)
{
return (double)u64 >= 0.0;
}
at -O3 on AArch64, GCC generates:
f:
ucvtf d31, x0
fcmpe d31, #0.0
csetw0, ge
ret
whereas LLVM gives:
f:
mov w0, #1
ret
i.e. it folds the comparison to constant true. GCC should do the same. This
would be useful in the context of code like the following:
unsigned long sqrtint(unsigned long a) {
return __builtin_sqrt(a);
}
for which GCC currently generates:
sqrtint:
ucvtf d0, x0
fcmpd0, #0.0
bpl .L5
stp x29, x30, [sp, -16]!
mov x29, sp
bl sqrt
ldp x29, x30, [sp], 16
fcvtzu x0, d0
ret
.L5:
fsqrt d0, d0
fcvtzu x0, d0
ret
i.e. it tests if the input is non-negative so that errno can be set correctly,
but the test is redundant since the input is necessarily non-negative. Indeed
LLVM generates:
sqrtint:
ucvtf d0, x0
fsqrt d0, d0
fcvtzu x0, d0
ret
for this case.
[Bug rtl-optimization/120050] [15/16 Regression] ICE bootstrapping on mips64el with --with-arch=gs464 --with-build-config=bootstrap-O3 --enable-checking=yes,extra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120050 --- Comment #9 from Xi Ruoyao --- https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683277.html
[Bug fortran/120179] [15 Regression] Failure with do concurrent and semicolon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120179 Thomas Schwinge changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||tschwinge at gcc dot gnu.org --- Comment #8 from Thomas Schwinge --- (In reply to GCC Commits from comment #5) > commit r16-480-g6ce73ad4370c143a7d1e6a13b1d353db5884213f > * gfortran.dg/do_concurrent_basic.f90: Extend testcase. I noticed this removed execution and torture testing; maybe unintentionally? -PASS: gfortran.dg/do_concurrent_basic.f90 -O0 (test for excess errors) -PASS: gfortran.dg/do_concurrent_basic.f90 -O0 execution test -PASS: gfortran.dg/do_concurrent_basic.f90 -O1 (test for excess errors) -PASS: gfortran.dg/do_concurrent_basic.f90 -O1 execution test -PASS: gfortran.dg/do_concurrent_basic.f90 -O2 (test for excess errors) -PASS: gfortran.dg/do_concurrent_basic.f90 -O2 execution test -PASS: gfortran.dg/do_concurrent_basic.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) -PASS: gfortran.dg/do_concurrent_basic.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test -PASS: gfortran.dg/do_concurrent_basic.f90 -O3 -g (test for excess errors) -PASS: gfortran.dg/do_concurrent_basic.f90 -O3 -g execution test -PASS: gfortran.dg/do_concurrent_basic.f90 -Os (test for excess errors) -PASS: gfortran.dg/do_concurrent_basic.f90 -Os execution test +PASS: gfortran.dg/do_concurrent_basic.f90 -O (test for excess errors)
[Bug tree-optimization/120231] GCC fails to notice that (double)u64 is non-negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 CC||amacleod at redhat dot com, ||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2025-05-12 --- Comment #1 from Jakub Jelinek --- I think we don't have value range handlers for casts from integers to floating point, from floating point to integers and their reverse operations, and it would certainly be desirable to add those. Say if we know that some integer SSA_NAME has [42, 48] range, then the frange when that is converted to say double will be [42.0, 48.0]. Of course, when the boundary values can't be converted exactly, we need to take it into account etc.
[Bug c++/93788] Segfault caused by infinite loop in cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93788 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #5 from mcccs at gmx dot com --- Works with: 4.4.7, fails with: 4.5.3
[Bug libstdc++/120235] std::fabs(const std::complex&) should not be defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120235 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-05-12 --- Comment #1 from Jonathan Wakely --- We should deprecate it then remove it.
[Bug tree-optimization/120219] [16 Regression] ~11% slowdown of 548.exchange2_r on x86_64 (maybe also on aarch64?) since r16-448-g8335fd561fa823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120219
Jan Hubicka changed:
What|Removed |Added
Depends on||119902
--- Comment #5 from Jan Hubicka ---
PR119919 was introduced by fixing part costs of promote/demote which disabled
vectorization of:
int a[9*9];
bool b[9];
void test()
{
for (int i = 0; i < 9; i++)
{
b[i] = a[i*9] != 0;
}
}
The underlying problem is bad costing of open-coded scatter. Cost of open-coded
scatter incorrectly assumes that offsets will be loaded as vectors and
converted to integers for address computation, while real code does all address
computations in integers, saving a lot of sse->int conversions. This is
PR119902.
My patch for pr119919 fixed other problem of costing this conversion which made
the code to barely pass the cost threshold. Later my commit
g:2c8d632d9ed4e3aeee2156ba17fe631ecbc90dbf fixed float<->int conversion costs
which made the cost test to fail again at generic tuning but not at native
tuning.
But still I am not sure how this is related to Andrew's patch and arm
performance can not be affected by these changes.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119902
[Bug 119902] open-coded scatter/gather should not account vec_to_scalar cost
[Bug libstdc++/120235] New: std::fabs(const std::complex&) should not be defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120235
Bug ID: 120235
Summary: std::fabs(const std::complex&) should not be
defined
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
TR1 defined std::tr1::fabs (8.1.8 [tr.c99.cmplx.fabs]) but this is not present
in the C++ standard. We should not define it in :
template
inline _Tp
/// fabs(__z) [8.1.8].
// Effects: Behaves the same as C99 function cabs, defined
//in subclause 7.3.8.1.
fabs(const std::complex<_Tp>& __z)
{ return std::abs(__z); }
This should not compile:
#include
auto x = std::fabs(std::complex{});
[Bug libstdc++/120235] std::fabs(const std::complex&) should not be defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120235 --- Comment #2 from Jonathan Wakely --- Aha, it was present in a C++0x draft but removed by https://cplusplus.github.io/LWG/issue595
[Bug rtl-optimization/120169] [m68k] internal compiler error: in maybe_record_trace_start, at dwarf2cfi.cc:2591 with LRA enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120169
--- Comment #6 from Andreas Schwab ---
Reduced test case:
typedef void *decl_node;
bool decl_isRecordField(decl_node);
void decl_lookupSym(int);
void mcDebug_assert(bool);
typedef enum { decl_varient } decl_nodeT;
typedef struct decl_nodeRec_r *decl_node__opaque;
struct decl_nodeRec_r {
decl_nodeT kind;
};
decl_node__opaque tag, putVarientTag_tag, putVarientTag_v,
decl_buildVarientSelector_f;
int decl_buildVarientSelector_tag;
decl_node decl_buildVarientSelector_type;
void decl_buildVarientSelector() {
mcDebug_assert(0);
if (decl_buildVarientSelector_type) {
decl_lookupSym(decl_buildVarientSelector_tag);
mcDebug_assert(0);
switch (putVarientTag_v->kind)
case decl_varient:
tag = putVarientTag_tag;
} else {
bool __trans_tmp_2 = decl_isRecordField(decl_buildVarientSelector_f);
mcDebug_assert(__trans_tmp_2);
mcDebug_assert(0);
switch (putVarientTag_v->kind)
case decl_varient:
tag = putVarientTag_tag;
}
}
[Bug fortran/120179] [15 Regression] Failure with do concurrent and semicolon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120179 --- Comment #9 from Tobias Burnus --- (In reply to Thomas Schwinge from comment #8) > > * gfortran.dg/do_concurrent_basic.f90: Extend testcase. > > I noticed this removed execution and torture testing; maybe unintentionally? I think THAT's FINE. The old code just had: integer :: i, arr(10) do concurrent (i = 1:10) arr(i) = i end do print *, arr That's somewhat useful at execution for debugging the code (printing the value of 'arr') - but as runtime test it just checks that it doesn't crash as not even the value of 'arr' is checked for. The updated test added two one-line tests, similar to comment 0 and changed 'compile' to 'run'.
[Bug rtl-optimization/120169] [m68k] internal compiler error: in maybe_record_trace_start, at dwarf2cfi.cc:2591 with LRA enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120169 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-05-12 Ever confirmed|0 |1
[Bug middle-end/120240] addcc/negcc/notcc vs cond_add/cond_neg/cond_one_cmpl optabs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120240 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-05-12 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- I should mention I noticed this when I was looking into cmov optab and trying to understand how it was unused (still). I am going to do some documentation changes here but won't be for another few weeks so I am filing this as a reminder for me to do it.
[Bug tree-optimization/120231] GCC fails to notice that (double)u64 is non-negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231 --- Comment #3 from Jakub Jelinek --- Yeah, I'd definitely appreciate blank handlers for those, which I can gradually try to implement. Working now on big-endian _BitInt, so it won't be immediately, but will try to get to it before summer.
Custom Packaging Boxes and Labels
Hi, We provide custom packaging boxes and labels. We make boxes in different materials and styles such as Vape Boxe, Cigarette Boxes, Cartridge Boxes, Cardboard boxes, Rigid Boxes and Mailer boxes, etc. Our benefits include quick turnaround time, free shipping and design support. Just send over your box or label specifications and quantity so I can give you an estimate on that. Let me know if you have any questions. Thanks Best Regards Kylo Pedro My Packaging Pro
[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 #7 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b4b4dfbd22e06877052bd4cc4b191d9d138155cf commit r16-570-gb4b4dfbd22e06877052bd4cc4b191d9d138155cf Author: Jason Merrill Date: Mon May 12 11:53:03 2025 -0400 c+: -Wabi false positive [PR120012] The warning compares the position of a field depending on whether or not the previous base/field is considered a POD for layout, but failed to consider whether the previous base/field is empty; layout of an empty base doesn't consider PODness. PR c++/120012 gcc/cp/ChangeLog: * class.cc (check_non_pod_aggregate): Check is_empty_class. gcc/testsuite/ChangeLog: * g++.dg/abi/base-defaulted2.C: New test.
[Bug tree-optimization/54240] Routine hoist_adjacent_loads does not work properly after r189366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54240 --- Comment #14 from Andrew Pinski --- (In reply to Bill Schmidt from comment #11) > My guess is that cmov_optab should probably be removed as unused. I filed PR 120230 for that and submitted a patch for the removal.
[Bug middle-end/120230] cmov_optab is not used for expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120230 --- Comment #2 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683366.html
[Bug target/120242] New: [15/16 regression] RISC-V: Miscompile at -O[23]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120242
Bug ID: 120242
Summary: [15/16 regression] RISC-V: Miscompile at -O[23]
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ewlu at rivosinc dot com
Target Milestone: ---
Testcase:
char f1(char a, char b) {
return b == 0 ? a : b;
}
int f2(int a, int b) {
return b ? a : 0;
}
struct l {
unsigned m;
int n;
};
struct l ae;
char af = -2;
unsigned ah = 4;
int aj = 8;
int *test = &aj;
int main() {
ao:
if (f2(f1(4, af++), *test) <= 0) {
for (; ae.n; ae.n++)
;
if (ah)
goto ao;
}
__builtin_printf("%d\n", af);
}
Commands:
-O3
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
> -O3 red.c -o user-config.out -fsigned-char -fno-strict-aliasing -fwrapv
> QEMU_CPU=rv64,vlen=128,rvv_ta_all_1s=true,rvv_ma_all_1s=true,v=true,vext_spec=v1.0,zve32f=true,zve64f=true
> timeout --verbose -k 0.1 4
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/qemu-riscv64 user-config.out
> 12
2
-O2
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
> -O2 red.c -o user-config.out -fsigned-char -fno-strict-aliasing -fwrapv
> QEMU_CPU=rv64,vlen=128,rvv_ta_all_1s=true,rvv_ma_all_1s=true,v=true,vext_spec=v1.0,zve32f=true,zve64f=true
> timeout --verbose -k 0.1 4
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/qemu-riscv64 user-config.out
> 12
2
-O1
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
> -O1 red.c -o user-config.out -fsigned-char -fno-strict-aliasing -fwrapv
> QEMU_CPU=rv64,vlen=128,rvv_ta_all_1s=true,rvv_ma_all_1s=true,v=true,vext_spec=v1.0,zve32f=true,zve64f=true
> timeout --verbose -k 0.1 4
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/qemu-riscv64 user-config.out
> 12
1
Bisected to r15-9239-g4d7a634f6d4 as the first bad commit
Found via fuzzer
[Bug target/120242] [15/16 regression] RISC-V: Miscompile at -O[23] since r15-9239-g4d7a634f6d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120242 Sam James changed: What|Removed |Added Target Milestone|--- |15.2 Summary|[15/16 regression] RISC-V: |[15/16 regression] RISC-V: |Miscompile at -O[23]|Miscompile at -O[23] since ||r15-9239-g4d7a634f6d4 CC||rsandifo at gcc dot gnu.org Keywords||wrong-code
[Bug fortran/120179] [15 Regression] Failure with do concurrent and semicolon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120179 --- Comment #10 from anlauf at gcc dot gnu.org --- (In reply to Thomas Schwinge from comment #8) > (In reply to GCC Commits from comment #5) > > commit r16-480-g6ce73ad4370c143a7d1e6a13b1d353db5884213f > > > * gfortran.dg/do_concurrent_basic.f90: Extend testcase. > > I noticed this removed execution and torture testing; maybe unintentionally? No, that was intentional. It does not make sense to torture-test here, as this is basically a parsing test and maybe for debugging. The added two lines are modelled after comment#0. They gave slightly different bogus errors before the patch, maybe due to slightly different error recovery after the hiccup. The additional line helps to ensure that there is nothing special going on here.
[Bug modula2/120188] documented example does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120188 --- Comment #6 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:9ce4c801e8275fcf0336ae2fb548f6ebb3ca068b commit r16-567-g9ce4c801e8275fcf0336ae2fb548f6ebb3ca068b Author: Gaius Mulley Date: Mon May 12 17:59:00 2025 +0100 PR modula2/120188: documented example does not work assignvalue m2plugin This patch corrects the gm2 command line used in the documentation to invoke the m2-plugin. The patch also includes the documentation example in dejagnu test code with an expect script to check whether plugins were enabled. gcc/ChangeLog: PR modula2/120188 * doc/gm2.texi (Semantic checking): Add -fm2-plugin command line option. gcc/testsuite/ChangeLog: PR modula2/120188 * lib/gm2-dg.exp (gm2-dg-frontend-configure-check): New function. (gm2-dg-runtest): Add -O2 to the option_list. * gm2.dg/doc/examples/plugin/fail/assignvalue.mod: New test. * gm2.dg/doc/examples/plugin/fail/doc-examples-plugin-fail.exp: New test. Signed-off-by: Gaius Mulley
[Bug tree-optimization/120231] GCC fails to notice that (double)u64 is non-negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231 --- Comment #2 from Andrew Macleod --- We do not have cast operators between int and float. We are also missing some dispatch code for them as we haven't actually used some of those patterns yet. I am going to checked in a patch to trunk shortly using this PR as a tag. It supplies the needed patterns and blank versions of the required operator methods for each cast. These are located near the bottom of range-op-float.cc. These functions currently return false, which is the default behaviour if the functions did not exist. // Cast Float to Integer bool operator_cast::fold_range (irange &lhs, tree type, const frange &op1, const irange &, relation_trio) const; bool operator_cast::op1_range (frange &op1, tree type, const irange &lhs, const irange &, relation_trio) const; // Cast Integer to Float. bool operator_cast::fold_range (frange &lhs, tree type, const irange &op1, const frange &, relation_trio) const; bool operator_cast::op1_range (irange &op1, tree type, const frange &lhs, const frange &, relation_trio) const; Feel free to populate them for this PR. If I get a chance and no one else does, I may do some simple population. but it wont be complex since I'm not familiar with working on floats.
[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 #8 from GCC Commits --- The releases/gcc-15 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:c9e3181516f1c0786f81b9c813581bf986a6300a commit r15-9664-gc9e3181516f1c0786f81b9c813581bf986a6300a Author: Jason Merrill Date: Mon May 12 11:53:03 2025 -0400 c+: -Wabi false positive [PR120012] The warning compares the position of a field depending on whether or not the previous base/field is considered a POD for layout, but failed to consider whether the previous base/field is empty; layout of an empty base doesn't consider PODness. PR c++/120012 gcc/cp/ChangeLog: * class.cc (check_non_pod_aggregate): Check is_empty_class. gcc/testsuite/ChangeLog: * g++.dg/abi/base-defaulted2.C: New test. (cherry picked from commit b4b4dfbd22e06877052bd4cc4b191d9d138155cf)
[Bug libstdc++/120187] Inclusion of ciso646 incorrectly points to using version in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120187 --- Comment #8 from GCC Commits --- The releases/gcc-15 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:506cb05479ee04c724eb0ebde07d2e9062efb264 commit r15-9666-g506cb05479ee04c724eb0ebde07d2e9062efb264 Author: Jonathan Wakely Date: Fri May 9 10:23:05 2025 +0100 libstdc++: Remove #warning from for C++17 [PR120187] Although was removed from C++20, it was not formally deprecated in C++17. In contrast, , , etc. were formally deprecated in C++17 before being removed in C++20. Due to the widespread convention of including to detect implementation-specific macros (such as _GLIBCXX_RELEASE) it causes quite a lot of noise to issue deprecation warnings in C++17 mode. The recommendation to include instead does work for recent compilers, even in C++17 mode, but isn't portable to older compilers that don't provide yet (e.g. GCC 8). There are also potential objections to including pre-C++20 when it wasn't defined by the standard. I don't have much sympathy for this position, because including for implementation-specific macros wasn't part of the C++17 standard either. It's no more non-standard to rely on being present and defining those macros than to rely on defining them, and __has_include can be used to detect whether is present. However, is being used in the wild by popular libraries like Abseil and we can't change versions of those that have already been released. This removes the #warning in for C++17 mode, so that we only emit diagnostics for C++20 and later. With this change, including in C++20 or later gives an error if _GLIBCXX_USE_DEPRECATED is defined to zero, otherwise a warning if -Wdeprecated is enabled, otherwise no diagnostic is given. This also adds "@since C++11 (removed in C++20)" to the Doxygen @file comments in all the relevant headers. The test for needs to be updated to no longer expect a warning for c++17_only. A new test is added to ensure that we get a warning instead of an error when -D_GLIBCXX_USE_DEPRECATED=0 is not used. libstdc++-v3/ChangeLog: PR libstdc++/120187 * include/c_global/ciso646: Only give deprecated warning for C++20 and later. * include/c_global/ccomplex: Add @since to Doxygen comment. * include/c_global/cstdalign: Likewise. * include/c_global/cstdbool: Likewise. * include/c_global/ctgmath: Likewise. * testsuite/18_support/headers/ciso646/macros.cc: Remove dg-warning for c++17_only effective target. * testsuite/18_support/headers/ciso646/macros-2.cc: New test. Reviewed-by: Tomasz KamiÅski (cherry picked from commit af062510f4179aa7b13e632f77593deee8fe29f2)
[Bug libstdc++/120198] [14/15 Regression] std::scoped_lock disabled for non-gthread environments (such as arm-none-eabi)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120198 --- Comment #5 from GCC Commits --- The releases/gcc-15 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d06a800159df2057d8d2fc028a3a90af937d606d commit r15-9665-gd06a800159df2057d8d2fc028a3a90af937d606d Author: Jonathan Wakely Date: Fri May 9 17:50:52 2025 +0100 libstdc++: Restore std::scoped_lock for non-gthreads targets [PR120198] This was a regression introduced with using version.def to define feature test macros (r14-3248-g083b7f2833d71d). std::scoped_lock doesn't need to depend on gthreads and so can be defined unconditionally, even for freestanding. libstdc++-v3/ChangeLog: PR libstdc++/120198 * include/bits/version.def (scoped_lock): Do not depend on gthreads or hosted. * include/bits/version.h: Regenerate. * include/std/mutex (scoped_lock): Update comment. * testsuite/30_threads/scoped_lock/requirements/typedefs.cc: Remove dg-require-gthreads and use custom lockable type instead of std::mutex. Check that typedef is only present for a single template argument. Reviewed-by: Tomasz KamiÅski (cherry picked from commit bdd2753f5f021a15a6c4ef02565356985fea1300)
[Bug libstdc++/120187] Inclusion of ciso646 incorrectly points to using version in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120187 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jonathan Wakely --- For GCC 15.2 I've removed the warning in C++17 mode.
[Bug libstdc++/120235] std::fabs(const std::complex&) should not be defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120235 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |16.0 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug target/110812] Check availability of builtins at expand time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812 Palmer Dabbelt changed: What|Removed |Added CC||palmer at gcc dot gnu.org --- Comment #8 from Palmer Dabbelt --- Looks like our TARGET_OPTION_RESTORE is just bogus?
[Bug fortran/119986] Complex array part references are being passed incorrectly to a procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986 --- Comment #12 from GCC Commits --- The releases/gcc-14 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:4a0e88c0c329ee69b13cdf2784c0c88edbca1f9e commit r14-11765-g4a0e88c0c329ee69b13cdf2784c0c88edbca1f9e Author: Harald Anlauf Date: Sat May 3 20:35:57 2025 +0200 Fortran: array subreferences and components of derived types [PR119986] PR fortran/119986 gcc/fortran/ChangeLog: * expr.cc (is_subref_array): When searching for array references, do not terminate early so that inquiry references to complex components work. * primary.cc (gfc_variable_attr): A substring reference can refer to either a scalar or array character variable. Adjust search accordingly. gcc/testsuite/ChangeLog: * gfortran.dg/actual_array_subref.f90: New test. (cherry picked from commit fceb6022798b587c9111d0241aaff72602dcd626)
[Bug ipa/120236] New: wrong code at -O{s,2,3} with "-fno-tree-fre -fipa-pta" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120236
Bug ID: 120236
Summary: wrong code at -O{s,2,3} with "-fno-tree-fre -fipa-pta"
on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/jjrdsPYTn
This appears to affect all versions, so perhaps a known issue?
[507] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250512 (experimental) (GCC)
[508] %
[508] % gcctk -O3 small.c; ./a.out
[509] %
[509] % gcctk -O3 -fno-tree-fre -fipa-pta small.c
[510] % ./a.out
Aborted
[511] %
[511] % cat small.c
int a, b, *c = &b;
int main() {
while (a) {
int ***d;
*d = &c;
a = ***d;
if (b)
__builtin_abort();
}
*c = 1;
if (!b)
__builtin_abort();
return 0;
}
[Bug libstdc++/120198] [14/15/16 Regression] std::scoped_lock disabled for non-gthread environments (such as arm-none-eabi)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120198 --- Comment #4 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:bdd2753f5f021a15a6c4ef02565356985fea1300 commit r16-556-gbdd2753f5f021a15a6c4ef02565356985fea1300 Author: Jonathan Wakely Date: Fri May 9 17:50:52 2025 +0100 libstdc++: Restore std::scoped_lock for non-gthreads targets [PR120198] This was a regression introduced with using version.def to define feature test macros (r14-3248-g083b7f2833d71d). std::scoped_lock doesn't need to depend on gthreads and so can be defined unconditionally, even for freestanding. libstdc++-v3/ChangeLog: PR libstdc++/120198 * include/bits/version.def (scoped_lock): Do not depend on gthreads or hosted. * include/bits/version.h: Regenerate. * include/std/mutex (scoped_lock): Update comment. * testsuite/30_threads/scoped_lock/requirements/typedefs.cc: Remove dg-require-gthreads and use custom lockable type instead of std::mutex. Check that typedef is only present for a single template argument. Reviewed-by: Tomasz KamiÅski
[Bug libstdc++/120187] Inclusion of ciso646 incorrectly points to using version in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120187 --- Comment #7 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:af062510f4179aa7b13e632f77593deee8fe29f2 commit r16-558-gaf062510f4179aa7b13e632f77593deee8fe29f2 Author: Jonathan Wakely Date: Fri May 9 10:23:05 2025 +0100 libstdc++: Remove #warning from for C++17 [PR120187] Although was removed from C++20, it was not formally deprecated in C++17. In contrast, , , etc. were formally deprecated in C++17 before being removed in C++20. Due to the widespread convention of including to detect implementation-specific macros (such as _GLIBCXX_RELEASE) it causes quite a lot of noise to issue deprecation warnings in C++17 mode. The recommendation to include instead does work for recent compilers, even in C++17 mode, but isn't portable to older compilers that don't provide yet (e.g. GCC 8). There are also potential objections to including pre-C++20 when it wasn't defined by the standard. I don't have much sympathy for this position, because including for implementation-specific macros wasn't part of the C++17 standard either. It's no more non-standard to rely on being present and defining those macros than to rely on defining them, and __has_include can be used to detect whether is present. However, is being used in the wild by popular libraries like Abseil and we can't change versions of those that have already been released. This removes the #warning in for C++17 mode, so that we only emit diagnostics for C++20 and later. With this change, including in C++20 or later gives an error if _GLIBCXX_USE_DEPRECATED is defined to zero, otherwise a warning if -Wdeprecated is enabled, otherwise no diagnostic is given. This also adds "@since C++11 (removed in C++20)" to the Doxygen @file comments in all the relevant headers. The test for needs to be updated to no longer expect a warning for c++17_only. A new test is added to ensure that we get a warning instead of an error when -D_GLIBCXX_USE_DEPRECATED=0 is not used. libstdc++-v3/ChangeLog: PR libstdc++/120187 * include/c_global/ciso646: Only give deprecated warning for C++20 and later. * include/c_global/ccomplex: Add @since to Doxygen comment. * include/c_global/cstdalign: Likewise. * include/c_global/cstdbool: Likewise. * include/c_global/ctgmath: Likewise. * testsuite/18_support/headers/ciso646/macros.cc: Remove dg-warning for c++17_only effective target. * testsuite/18_support/headers/ciso646/macros-2.cc: New test. Reviewed-by: Tomasz KamiÅski
[Bug other/120237] New: /pub/gcc/infrastructure/ + contrib/download_prerequisites: Update MPFR for C23 / Fortran 2023 functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120237 Bug ID: 120237 Summary: /pub/gcc/infrastructure/ + contrib/download_prerequisites: Update MPFR for C23 / Fortran 2023 functions Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- contrib/download_prerequisites currently downloads from http://gcc.gnu.org/pub/gcc/infrastructure/ gmp='gmp-6.2.1.tar.bz2' mpfr='mpfr-4.1.0.tar.bz2' mpc='mpc-1.2.1.tar.gz' isl='isl-0.24.tar.bz2' gettext='gettext-0.22.tar.gz' Current is: * GMP 6.3.0 (2023-07-30) → https://gmplib.org/ + https://gmplib.org/gmp6.3 * MPFR 6.2.2 (2025-03-25) → https://www.mpfr.org/ * MPC 1.3.1 (2022-12-15) → https://www.multiprecision.org/mpc/ * ISL 0.27 (2024-09-01) → https://libisl.sourceforge.io/ * gettext 0.25 (2025-05-) → https://savannah.gnu.org/projects/gettext/ Most relevant is the MPFR update as MPFR 4.2 added several functions for C23, cf. PR118592 and the added functions in MPFR 4.2, https://www.mpfr.org/mpfr-4.2.0/#changes For Fortran, the 'pi' (half-cycle) trigonometric functions (sinpi etc. - same as C23) are also relevant, PR113152. Additionally, the degree trigonometric functions, while not in C23, profit from the mpfr_...u functions of MPFR 4.2.0 → PR120225 → https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683279.html For gettext, I had hoped that gettext-tools/src/format-gcc-internal.c would be upto date, but it seems that no one followed up to PR119684 (→ PR119684 comment 6 & PR119684 comment 8 and ...).
[Bug libstdc++/119714] [15/16 Regression] Failure when using == operator on a class derived from std::expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119714 --- Comment #8 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:91bc8169edd9038d78f38bd813287d72e6345c26 commit r16-559-g91bc8169edd9038d78f38bd813287d72e6345c26 Author: Patrick Palka Date: Mon May 12 09:15:34 2025 -0400 libstdc++: Fix constraint recursion in std::expected's operator== [PR119714] This std::expected friend operator== is prone to constraint recursion after CWG 2369 for the same reason as basic_const_iterator's comparison operators were before the r15-7757-g4342c50ca84ae5 workaround. This patch works around the constraint recursion here in a similar manner, by making the function parameter of type std::expected dependent in a trivial way. PR libstdc++/119714 PR libstdc++/112490 libstdc++-v3/ChangeLog: * include/std/expected (expected::operator==): Replace non-dependent std::expected function parameter with a dependent one of type expected<_Vp, _Er> where _Vp matches _Tp. * testsuite/20_util/expected/119714.cc: New test. Reviewed-by: Tomasz KamiÅski Reviewed-by: Jonathan Wakely
[Bug c++/120238] [12/13/14/15/16 Regression] ICE (verify_gimple failed) since r12-657
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120238
--- Comment #2 from Richard Biener ---
This looks like a frontend issue to me,the CTOR {&e, 0} has 'e' without
TREE_ADDESSABLE set.
We used to paper over such FE issues during gimplification and wherenot, but
not so any longer.
Note that we _do_ eventually still set TREE_ADDRESSABLE when during SSA
optimizations we create such stmt and call update_stmt on it. Still the
frontend needs to set TREE_ADDRESSABLE when it takes the address of a
variable.
[Bug c++/119692] C++ 'typeinfo', 'vtable' vs. OpenACC, OpenMP 'target' offloading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119692
--- Comment #7 from GCC Commits ---
The trunk branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:b5f48e7872db30b8f174cb2c497868a358bf75d6
commit r16-566-gb5f48e7872db30b8f174cb2c497868a358bf75d6
Author: Thomas Schwinge
Date: Fri May 9 14:49:03 2025 +0200
GCN, nvptx offloading: Restrain 'WARNING: program timed out.' while in
'dynamic_cast'" [PR119692]
PR target/119692
libgomp/
* testsuite/libgomp.c++/pr119692-1-4.C: '{ dg-timeout 10 }'.
* testsuite/libgomp.c++/pr119692-1-5.C: Likewise.
* testsuite/libgomp.c++/target-exceptions-bad_cast-1.C: Likewise.
* testsuite/libgomp.c++/target-exceptions-bad_cast-2.C: Likewise.
* testsuite/libgomp.oacc-c++/exceptions-bad_cast-1.C: Likewise.
* testsuite/libgomp.oacc-c++/exceptions-bad_cast-2.C: Likewise.
[Bug target/116445] gcc.target/arm/unsigned-extend-2.c on Cortex-M55 and misses possible Cortex-M optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116445 --- Comment #7 from GCC Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:20c25919132b497c3a46a4bc4044f65b6459b99e commit r16-562-g20c25919132b497c3a46a4bc4044f65b6459b99e Author: Christophe Lyon Date: Tue Apr 8 16:24:18 2025 + testsuite: arm: Fix unsigned-extend-2.c [PR116445] The test was designed to pass with thumb2, but code generation changed with the introduction of Low Overhead Loops, so the test can fail if one overrides the flags when running the testsuite. In addition, useless subtract / extension instructions require -O2 to remove them (-O is not sufficient), so replace -O with -O2 in dg-options. arm_thumb2_ok_no_arm_v8_1m_lob does not do what the test needs (it can fail because some flags conflict, rather than because lob are supported, and we do not need to check runtime support in this test anyway), so the patch reverts back to arm_thumb2_ok. Finally, replace the scan-assembler directives with check-function-bodies, checking both types of code generation (with and without LOL). Depending on architecture version, the two insns and r0, r1, r0, lsr #1 andsr3, r3, #255 can be swapped, so accept both orders. gcc/testsuite/ChangeLog: PR target/116445 * gcc.target/arm/unsigned-extend-2.c: Fix dg directives.
[Bug libstdc++/119645] GCN, nvptx: libstdc++ 'checking for atomic builtins [...]... no'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119645 --- Comment #3 from GCC Commits --- The trunk branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:1321df5bc05663021313c17f4af54b950aa05d01 commit r16-563-g1321df5bc05663021313c17f4af54b950aa05d01 Author: Thomas Schwinge Date: Mon May 12 11:06:47 2025 +0200 GCN, nvptx libstdc++: Force use of '__atomic' builtins: revert 'atomicity_dir=cpu/generic/atomicity_builtins' hard-coding [PR119645]" Thanks to commit 86627faec10da53d7532805019e5296fcf15ac09 "libstdc++: Rewrite atomic builtin checks [PR70560]", for both GCN, nvptx we now get: +configure:16060: checking for atomic builtins for _Atomic_word +[...] +configure:16073: result: yes ..., and thus may revert the 'atomicity_dir=cpu/generic/atomicity_builtins' hard-coding added in commit 059b5509c14904b55c37f659170240ae0d2c1c8e "GCN, nvptx libstdc++: Force use of '__atomic' builtins [PR119645]". PR target/119645 libstdc++-v3/ * configure.host [GCN, nvptx] (atomicity_dir): Don't set.
[Bug target/120223] [16 Regression] ICE: in extract_insn, at recog.cc:2882 unrecognizable insn: (xor:DI (reg:DI 136) (const_int ...)) with -mcpu=thead-c906
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120223 --- Comment #2 from Jeffrey A. Law --- Dumb mistake on my part. Testing a fix.
[Bug libstdc++/119427] std::erase_if(std::flat_map) does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119427 --- Comment #4 from GCC Commits --- The releases/gcc-15 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:0ff3b3122adfe0c479901da4fc28e367d89f185b commit r15-9659-g0ff3b3122adfe0c479901da4fc28e367d89f185b Author: Patrick Palka Date: Tue Apr 29 08:21:35 2025 -0400 libstdc++: Fix availability of std::erase_if(std::flat_foo) [PR119427] These std::erase_if overloads were wrongly implemented as hidden friends, visible only via ADL, so erase_if(x) would work but not std::erase_if(x). PR libstdc++/119427 libstdc++-v3/ChangeLog: * include/std/flat_map (_Flat_map_impl::erase_if): Replace this hidden friend with ... (_Flat_map_impl::_M_erase_if): ... this member function. (flat_map): Export _Flat_map_impl::_M_erase_if. (erase_if(flat_map)): Define. (flat_multimap): Export _Flat_map_impl::_M_erase_if. (erase_if(flat_multimap)): Define. * include/std/flat_set (_Flat_set_impl::erase_if): Replace with ... (_Flat_set_impl::_M_erase_if): ... this member function. (flat_set): Export _Flat_set_impl::_M_erase_if. (erase_if(flat_set)): Define. (flat_multiset): Export _Flat_set_impl::_M_erase_if. (erase_if(flat_multiset)): Define. * testsuite/23_containers/flat_map/1.cc (test07): New test. * testsuite/23_containers/flat_multimap/1.cc (test07): New test. * testsuite/23_containers/flat_multiset/1.cc (test09): New test. * testsuite/23_containers/flat_set/1.cc (test09): New test. Reviewed-by: Jonathan Wakely (cherry picked from commit aa93272cfd2233858da0792761387cc27f4d5ff3)
[Bug libstdc++/119714] [15/16 Regression] Failure when using == operator on a class derived from std::expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119714 --- Comment #9 from GCC Commits --- The releases/gcc-15 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:0b76b58a5875d519f95a5af661fb64e42a42ed8e commit r15-9660-g0b76b58a5875d519f95a5af661fb64e42a42ed8e Author: Patrick Palka Date: Mon May 12 09:15:34 2025 -0400 libstdc++: Fix constraint recursion in std::expected's operator== [PR119714] This std::expected friend operator== is prone to constraint recursion after CWG 2369 for the same reason as basic_const_iterator's comparison operators were before the r15-7757-g4342c50ca84ae5 workaround. This patch works around the constraint recursion here in a similar manner, by making the function parameter of type std::expected dependent in a trivial way. PR libstdc++/119714 PR libstdc++/112490 libstdc++-v3/ChangeLog: * include/std/expected (expected::operator==): Replace non-dependent std::expected function parameter with a dependent one of type expected<_Vp, _Er> where _Vp matches _Tp. * testsuite/20_util/expected/119714.cc: New test. Reviewed-by: Tomasz KamiÅski Reviewed-by: Jonathan Wakely (cherry picked from commit 91bc8169edd9038d78f38bd813287d72e6345c26)
[Bug libstdc++/112490] infinite meta error in reverse_iterator::iterator>> (LWG 4218)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112490 --- Comment #19 from GCC Commits --- The releases/gcc-15 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:0b76b58a5875d519f95a5af661fb64e42a42ed8e commit r15-9660-g0b76b58a5875d519f95a5af661fb64e42a42ed8e Author: Patrick Palka Date: Mon May 12 09:15:34 2025 -0400 libstdc++: Fix constraint recursion in std::expected's operator== [PR119714] This std::expected friend operator== is prone to constraint recursion after CWG 2369 for the same reason as basic_const_iterator's comparison operators were before the r15-7757-g4342c50ca84ae5 workaround. This patch works around the constraint recursion here in a similar manner, by making the function parameter of type std::expected dependent in a trivial way. PR libstdc++/119714 PR libstdc++/112490 libstdc++-v3/ChangeLog: * include/std/expected (expected::operator==): Replace non-dependent std::expected function parameter with a dependent one of type expected<_Vp, _Er> where _Vp matches _Tp. * testsuite/20_util/expected/119714.cc: New test. Reviewed-by: Tomasz KamiÅski Reviewed-by: Jonathan Wakely (cherry picked from commit 91bc8169edd9038d78f38bd813287d72e6345c26)
[Bug libstdc++/119714] [15/16 Regression] Failure when using == operator on a class derived from std::expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119714 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Patrick Palka --- Should be fixed for GCC 15.2, thanks for the bug report.
[Bug libstdc++/119645] GCN, nvptx: libstdc++ 'checking for atomic builtins [...]... no'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119645
Thomas Schwinge changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #4 from Thomas Schwinge ---
(In reply to GCC Commits from comment #3)
> commit r16-563-g1321df5bc05663021313c17f4af54b950aa05d01
> GCN, nvptx libstdc++: Force use of '__atomic' builtins: revert
> 'atomicity_dir=cpu/generic/atomicity_builtins' hard-coding [PR119645]"
>
> Thanks to commit 86627faec10da53d7532805019e5296fcf15ac09
> "libstdc++: Rewrite atomic builtin checks [PR70560]", for both GCN, nvptx
> we now get:
>
> +configure:16060: checking for atomic builtins for _Atomic_word
> +[...]
> +configure:16073: result: yes
>
> ..., and thus may revert the
> 'atomicity_dir=cpu/generic/atomicity_builtins'
> hard-coding added in commit 059b5509c14904b55c37f659170240ae0d2c1c8e
> "GCN, nvptx libstdc++: Force use of '__atomic' builtins [PR119645]".
>
> PR target/119645
> libstdc++-v3/
> * configure.host [GCN, nvptx] (atomicity_dir): Don't set.
... which reverts half of:
(In reply to GCC Commits from comment #2)
> commit r15-9256-g059b5509c14904b55c37f659170240ae0d2c1c8e
> GCN, nvptx libstdc++: Force use of '__atomic' builtins [PR119645]
The other half, however, we cannot revert, as we'd then for both GCN, nvptx
regress this one:
> -checking for lock policy for shared_ptr reference counts... mutex
> +checking for lock policy for shared_ptr reference counts... atomic
... due to:
configure:[...]: checking for lock policy for shared_ptr reference counts
[...]
-configure:16414: $? = 0
-configure:16430: result: atomic
+conftest.cpp:28:7: error: #error "No 2-byte compare-and-swap"
+ 28 | # error "No 2-byte compare-and-swap"
+ | ^
+configure:16162: $? = 1
+configure: failed program was:
+|[...]
+| #if ! defined __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2
+| # error "No 2-byte compare-and-swap"
+| #elif ! defined __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
+| # error "No 4-byte compare-and-swap"
+| #endif
+|
+| int
+| main ()
+| {
+|
+| ;
+| return 0;
+| }
+configure:16184: result: mutex
(That 'GLIBCXX_ENABLE_LOCK_POLICY' check has been challenged before: "Why do we
care about 2-byte CAS on targets with 4-byte _Atomic_word?!")
We thus keep that one hard-coded:
> PR target/119645
> libstdc++-v3/
> * acinclude.m4 (GLIBCXX_ENABLE_LOCK_POLICY) [GCN, nvptx]:
> Hard-code results.
[Bug c++/120123] [12/13/14/15/16 Regression] Implicit this is not used in a requires clause in nested lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120123 Patrick Palka changed: What|Removed |Added Keywords|needs-bisection | Ever confirmed|0 |1 Last reconfirmed||2025-05-12 CC||ppalka at gcc dot gnu.org Summary|[12/13/14/15 Regression]|[12/13/14/15/16 Regression] |Implicit this is not used |Implicit this is not used |in a requires clause in |in a requires clause in |nested lambdas |nested lambdas Status|UNCONFIRMED |NEW --- Comment #3 from Patrick Palka --- Confirmed
[Bug analyzer/120213] analyzer report a false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120213 --- Comment #7 from David Malcolm --- Reproducer on Compiler Explorer (with gcc trunk): https://godbolt.org/z/darnMzMr3
[Bug c++/120224] [14/15/16 Regression] ICE in cp_parser_expression_statement with std::void_t overload resolution since 14.1 until trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120224 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/120222] [16 Regression] FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "vectorized 1 loops" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120222 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug target/120186] [pa] internal compiler error: in fail, at selftest.cc:47 during bootstrap with LRA enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120186 --- Comment #6 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #5) > > You might try building with old reload. > > Can do that later. Building the same revision with reload works fine, so this issue is related to LRA.
[Bug fortran/119986] Complex array part references are being passed incorrectly to a procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.3 --- Comment #13 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-16, and backported to 15- and 14-branch. Closing. Thanks for the report!
[Bug middle-end/120230] cmov_optab is not used for expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120230 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |16.0 --- Comment #4 from Andrew Pinski --- Fixed.
[Bug c++/120161] [14/15/16 Regression] Deduction failure with nested dependent type with a class base classes of 2 of the inner type since r14-4112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120161 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org
[Bug middle-end/120230] cmov_optab is not used for expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120230 --- Comment #3 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:213c64962d24fa8a4b2f3d7a9c5508f9daed9fa2 commit r16-572-g213c64962d24fa8a4b2f3d7a9c5508f9daed9fa2 Author: Andrew Pinski Date: Sun May 11 22:11:38 2025 -0700 optabs: Remove cmov optab [PR120230] cmov optab was added back in r0-24110-g1c0290eaac4094 (https://gcc.gnu.org/pipermail/gcc-patches/1999-September/018596.html) but it was never used. movcc is used instead and since r0-93453-gf90b7a5a7913cc (cond-optab), movcc becomes what cmov_optab was going to be; in having a combined compare and move optab. Note the only target which seems to have implemented this optab is aarch64; will remove that in a different patch. Bootstrapped and tested on x86_64-linux-gnu. PR middle-end/120230 gcc/ChangeLog: * optabs.cc (can_compare_p): Remove support for ccp_cmov. * optabs.def (cmov_optab): Remove. * optabs.h (can_compare_purpose): Remove ccp_cmov. Signed-off-by: Andrew Pinski
[Bug cobol/119377] cobol.dg/group1/declarative_1.cob fails (segfaults, uninitialised vars)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377 --- Comment #11 from Robert Dubner --- I am not surprised. When I first read about it a couple of days ago, it looked to me like two separate problems. Primus: We talked casually about my working with you to duplicate the working environment on my Mac Mini. Is that something we can attempt? Secundus: There is a magic thing you can do that might...might!...give Jim and me some more information to work with, seeing as how without a working environment we have to work by remote control like this. I am assuming you can launch a compilation of that particular source code file. When you do, set the GCOBOL_SHOW environment variable to anything: GCOBOL_SHOW=1 gcobol declarative_1.cob The basic structure of the COBOL front end is that Jim's parsing code figures out what the programmer wants done, and the parser calls my target-code generating routines, which mostly are named "parser_" and "parser_". The GCOBOL_SHOW environment variable causes many of those parser_ routines to output that they have been called, and for many of them there is feedback about what variables they were passed. It's quite noisy, but sometimes invaluable. And in this case, it'll probably give us some idea of exactly where things are going south.
[Bug middle-end/118411] asm goto in large function miscompiles with "Error: bad immediate value for offset" in ARM mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118411 --- Comment #9 from GCC Commits --- The releases/gcc-13 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:1d961c62a7bc1521c977fe48d4cbd940d7ccb8ea commit r13-9651-g1d961c62a7bc1521c977fe48d4cbd940d7ccb8ea Author: Andrew Pinski Date: Fri Jan 10 20:04:09 2025 -0800 final: Fix get_attr_length for asm goto [PR118411] The problem is for inline-asm goto, the outer rtl insn type is a jump_insn and get_attr_length does not handle ASM specially unlike if the outer rtl insn type was just insn. This fixes the issue by adding support for both CALL_INSN and JUMP_INSN with asm. OK? Bootstrapped and tested on x86_64-linux-gnu. PR middle-end/118411 gcc/ChangeLog: * final.cc (get_attr_length_1): Handle asm for CALL_INSN and JUMP_INSNs. Signed-off-by: Andrew Pinski (cherry picked from commit c1729df6ec1eff4815a9cdd71392691ce21da028)
[Bug middle-end/118411] asm goto in large function miscompiles with "Error: bad immediate value for offset" in ARM mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118411 --- Comment #8 from GCC Commits --- The releases/gcc-14 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:102e10f0221150218e7ee61b47e42b50653052ae commit r14-11766-g102e10f0221150218e7ee61b47e42b50653052ae Author: Andrew Pinski Date: Fri Jan 10 20:04:09 2025 -0800 final: Fix get_attr_length for asm goto [PR118411] The problem is for inline-asm goto, the outer rtl insn type is a jump_insn and get_attr_length does not handle ASM specially unlike if the outer rtl insn type was just insn. This fixes the issue by adding support for both CALL_INSN and JUMP_INSN with asm. OK? Bootstrapped and tested on x86_64-linux-gnu. PR middle-end/118411 gcc/ChangeLog: * final.cc (get_attr_length_1): Handle asm for CALL_INSN and JUMP_INSNs. Signed-off-by: Andrew Pinski (cherry picked from commit c1729df6ec1eff4815a9cdd71392691ce21da028)
[Bug middle-end/118411] asm goto in large function miscompiles with "Error: bad immediate value for offset" in ARM mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118411 --- Comment #10 from GCC Commits --- The releases/gcc-12 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:41366ba6f6358fe6a3e9f631e513dffe2ea9db3a commit r12-11095-g41366ba6f6358fe6a3e9f631e513dffe2ea9db3a Author: Andrew Pinski Date: Fri Jan 10 20:04:09 2025 -0800 final: Fix get_attr_length for asm goto [PR118411] The problem is for inline-asm goto, the outer rtl insn type is a jump_insn and get_attr_length does not handle ASM specially unlike if the outer rtl insn type was just insn. This fixes the issue by adding support for both CALL_INSN and JUMP_INSN with asm. OK? Bootstrapped and tested on x86_64-linux-gnu. PR middle-end/118411 gcc/ChangeLog: * final.cc (get_attr_length_1): Handle asm for CALL_INSN and JUMP_INSNs. Signed-off-by: Andrew Pinski (cherry picked from commit c1729df6ec1eff4815a9cdd71392691ce21da028)
[Bug middle-end/21231] cmov and cstore standard names not documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21231 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > cmov optab is unused (PR120230). > Which means this is fixed for GCC 4.5.0. > I am testing a patch to remove cmov optab right now too. cmov was removed in r16-572 (but it was never used so documentation does not matter in the end).
[Bug c++/120142] [13/14/15/16 regression] internal compiler error: in tsubst, at cp/pt.cc:16670 since r13-6971-ga5de246535db1b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120142 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-05-12 Status|UNCONFIRMED |NEW --- Comment #2 from Patrick Palka --- A workaround is to replace the constrained auto template parameter with a requires-clause: -template _column column; +template requires concepts::property _column column;
[Bug middle-end/118411] asm goto in large function miscompiles with "Error: bad immediate value for offset" in ARM mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118411 Andrew Pinski changed: What|Removed |Added Known to work||12.4.1, 13.3.1, 14.2.1 Target Milestone|--- |12.5 Known to fail||12.4.0, 13.3.0, 14.2.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Andrew Pinski --- Fixed on all open branches now.
[Bug cobol/119377] cobol.dg/group1/declarative_1.cob fails (segfaults, uninitialised vars)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377
--- Comment #12 from Sam James ---
Created attachment 61409
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61409&action=edit
declarative_1.cob show output
(In reply to Robert Dubner from comment #11)
```
(gdb) r
Starting program: /usr/libexec/gcc/x86_64-pc-linux-gnu/16/cobol1
cobol.dg/group1/declarative_1.cob -quiet -dumpdir a- -dumpbase
declarative_1.cob -dumpbase-ext .cob -main=cobol.dg/group1/declarative_1.cob
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
yyparse () at
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./gcc/cobol/parse.y:7116
7116if( *$1 == '-' ) {
(gdb) t
[Current thread is 1 (Thread 0x77eaff00 (LWP 1829233))]
(gdb) bt
#0 yyparse () at
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./gcc/cobol/parse.y:7116
#1 0x57efe658 in parse_file (filename=0x7fffdb79
"cobol.dg/group1/declarative_1.cob") at
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./gcc/cobol/util.cc:2142
#2 cobol_parse_files (nfile=, files=) at
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./gcc/cobol/util.cc:2203
#3 0x57af6975 in compile_file () at
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./gcc/toplev.cc:451
#4 0x57ac3a92 in do_compile () at
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./gcc/toplev.cc:2211
#5 toplev::main (this=this@entry=0x7fffd5c6, argc=,
argv=) at
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./gcc/toplev.cc:2374
#6 0x57ac2aaa in main (argc=, argv=) at
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./gcc/main.cc:39
```
Attached the 'show' output too.
[Bug target/110812] Check availability of builtins at expand time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812
--- Comment #9 from Palmer Dabbelt ---
Which means we just need something like this?
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 38f3ae7cd84..5ed6c54ff1c 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -10868,14 +10868,75 @@ riscv_save_restore_target_globals (tree new_tree)
TREE_TARGET_GLOBALS (new_tree) = save_target_globals_default_opts ();
}
+/* Implements TARGET_OPTION_SAVE. Restore the backend codegen decisions
+ using the information saved in PTR. */
+
+static void
+riscv_option_save (struct cl_target_option *ptr,
+ struct gcc_options * /* opts_set */,
+ struct gcc_options *opts)
+{
+ ptr->x_target_flags = opts->x_target_flags;
+ ptr->x_riscv_stack_protector_guard_reg=
opts->x_riscv_stack_protector_guard_reg;
+ ptr->x_riscv_stack_protector_guard_offset =
opts->x_riscv_stack_protector_guard_offset;
+ ptr->x_riscv_zi_subext= opts->x_riscv_zi_subext;
+ ptr->x_riscv_za_subext= opts->x_riscv_za_subext;
+ ptr->x_riscv_zb_subext= opts->x_riscv_zb_subext;
+ ptr->x_riscv_zinx_subext = opts->x_riscv_zinx_subext;
+ ptr->x_riscv_zk_subext= opts->x_riscv_zk_subext;
+ ptr->x_riscv_vector_elen_flags= opts->x_riscv_vector_elen_flags;
+ ptr->x_riscv_zvl_flags= opts->x_riscv_zvl_flags;
+ ptr->x_riscv_zvb_subext = opts->x_riscv_zvb_subext;
+ ptr->x_riscv_zvk_subext = opts->x_riscv_zvk_subext;
+ ptr->x_riscv_zicmo_subext = opts->x_riscv_zicmo_subext;
+ ptr->x_riscv_mop_subext = opts->x_riscv_mop_subext;
+ ptr->x_riscv_zf_subext= opts->x_riscv_zf_subext;
+ ptr->x_riscv_zfa_subext = opts->x_riscv_zfa_subext;
+ ptr->x_riscv_zm_subext= opts->x_riscv_zm_subext;
+ ptr->x_riscv_zc_subext= opts->x_riscv_zc_subext;
+ ptr->x_riscv_sv_subext= opts->x_riscv_sv_subext;
+ ptr->x_riscv_ztso_subext = opts->x_riscv_ztso_subext;
+ ptr->x_riscv_xcv_subext = opts->x_riscv_xcv_subext;
+ ptr->x_riscv_xthead_subext= opts->x_riscv_xthead_subext;
+ ptr->x_riscv_xventana_subext = opts->x_riscv_xventana_subext;
+ ptr->x_riscv_sifive_subext= opts->x_riscv_sifive_subext;
+ ptr->x_riscv_fmv_priority = opts->x_riscv_fmv_priority;
+
+}
+
/* Implements TARGET_OPTION_RESTORE. Restore the backend codegen decisions
using the information saved in PTR. */
static void
riscv_option_restore (struct gcc_options *opts,
struct gcc_options * /* opts_set */,
- struct cl_target_option * /* ptr */)
-{
+ struct cl_target_option *ptr)
+{
+ opts->x_target_flags = ptr->x_target_flags;
+ opts->x_riscv_stack_protector_guard_reg=
ptr->x_riscv_stack_protector_guard_reg;
+ opts->x_riscv_stack_protector_guard_offset =
ptr->x_riscv_stack_protector_guard_offset;
+ opts->x_riscv_zi_subext= ptr->x_riscv_zi_subext;
+ opts->x_riscv_za_subext= ptr->x_riscv_za_subext;
+ opts->x_riscv_zb_subext= ptr->x_riscv_zb_subext;
+ opts->x_riscv_zinx_subext = ptr->x_riscv_zinx_subext;
+ opts->x_riscv_zk_subext= ptr->x_riscv_zk_subext;
+ opts->x_riscv_vector_elen_flags= ptr->x_riscv_vector_elen_flags;
+ opts->x_riscv_zvl_flags= ptr->x_riscv_zvl_flags;
+ opts->x_riscv_zvb_subext = ptr->x_riscv_zvb_subext;
+ opts->x_riscv_zvk_subext = ptr->x_riscv_zvk_subext;
+ opts->x_riscv_zicmo_subext = ptr->x_riscv_zicmo_subext;
+ opts->x_riscv_mop_subext = ptr->x_riscv_mop_subext;
+ opts->x_riscv_zf_subext= ptr->x_riscv_zf_subext;
+ opts->x_riscv_zfa_subext = ptr->x_riscv_zfa_subext;
+ opts->x_riscv_zm_subext= ptr->x_riscv_zm_subext;
+ opts->x_riscv_zc_subext= ptr->x_riscv_zc_subext;
+ opts->x_riscv_sv_subext= ptr->x_riscv_sv_subext;
+ opts->x_riscv_ztso_subext = ptr->x_riscv_ztso_subext;
+ opts->x_riscv_xcv_subext = ptr->x_riscv_xcv_subext;
+ opts->x_riscv_xthead_subext= ptr->x_riscv_xthead_subext;
+ opts->x_riscv_xventana_subext = ptr->x_riscv_xventana_subext;
+ opts->x_riscv_sifive_subext= ptr->x_riscv_sifive_subext;
+ opts->x_riscv_fmv_priority = ptr->x_riscv_fmv_priority;
riscv_override_options_internal (opts);
}
@@ -14046,6 +14107,9 @@ bool need_shadow_stack_push_pop_p ()
#undef TARGET_OPTION_OVERRIDE
#de
[Bug tree-optimization/120231] GCC fails to notice that (double)u64 is non-negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231 --- Comment #4 from GCC Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:6f375445ef09d5c97d5bcc0fcb6069612217963e commit r16-571-g6f375445ef09d5c97d5bcc0fcb6069612217963e Author: Andrew MacLeod Date: Mon May 12 11:41:37 2025 -0400 Add dispatch for casts between integer and float. GCC currently does not implement range operators for casting between integers and float. This patch adds the missing dispatch patterns and routines to facilitate implmenting these casts. PR tree-optimization/120231 * range-op-float.cc (operator_cast::fold_range): New variants. (operator_cast::op1_range): Likewise. * range-op-mixed.h (operator_cast::fold_range): Likewise. (operator_cast::op1_range): Likewise * range-op.cc (range_op_handler::fold_range): Add RO_FIF dispatch. (range_op_handler::op1_range): Add RO_IFF and RO_FII patterns. (range_operator::fold_range): Provide new variant default. (range_operator::op1_range): Likewise. * range-op.h (range_operator): Add new variant methods.
[Bug c++/120243] [15/16 Regression] Exception rethrown from coroutine promise type unhandled_exception not caught under -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243
--- Comment #1 from TC ---
A similar example but with an initially suspended coroutine terminates at -O2
or highter.
#include
struct coro {
struct promise_type {
promise_type() = default;
std::suspend_always initial_suspend() const noexcept { return {}; }
std::suspend_always final_suspend() const noexcept { return {}; }
void unhandled_exception() { throw; }
coro get_return_object() { return
{std::coroutine_handle::from_promise(*this)}; }
void return_void() {}
};
std::coroutine_handle h;
};
int main() {
auto c = []() -> coro {
throw "hello";
__builtin_abort();
co_return;
};
try {
c().h.resume();
}
catch(...) {
__builtin_printf("Caught!\n");
}
}
[Bug c++/120243] New: [15/16 Regression] Exception rethrown from coroutine promise type unhandled_exception not caught under -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243
Bug ID: 120243
Summary: [15/16 Regression] Exception rethrown from coroutine
promise type unhandled_exception not caught under -O1
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
#include
struct coro {
struct promise_type {
promise_type() = default;
std::suspend_never initial_suspend() const noexcept { return {}; }
std::suspend_never final_suspend() const noexcept { return {}; }
void unhandled_exception() { throw; }
coro get_return_object() { return {}; }
void return_void() {}
};
};
int main() {
auto c = []() -> coro {
throw "hello";
__builtin_abort();
co_return;
};
try {
c();
}
catch(...) {
__builtin_printf("Caught!\n");
}
}
This prints "Caught!" with -O0 but terminates with
> terminate called after throwing an instance of 'char const*'
with -O1 or higher.
[Bug cobol/120244] New: cobol.dg/cgroup2: more Valgrind issues in tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120244
Bug ID: 120244
Summary: cobol.dg/cgroup2: more Valgrind issues in tests
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: testsuite-fail
Severity: normal
Priority: P3
Component: cobol
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
CC: rdubner at gcc dot gnu.org
Target Milestone: ---
I'd encourage running the testsuite with a GCC built using
--enable-checking=valgrind --enable-valgrind-annotations. You can use the
commits at https://forge.sourceware.org/sjames/gcc/commits/branch/sam-valgrind
to make it fatal rather than just emitting noise during the testsuite to make
sure things fail too, if you wish (not all tests will fail on unexpected
output).
Using a quick loop just to see what happens, outside of a proper testsuite run
(and --enable-checking=valgrind), I see:
```
~/git/gcc/gcc/testsuite $ for x in cobol.dg/*/*.cob ; do (set -x ; gcobol ${x}
-wrapper valgrind,-q ; set +x) ; done
[...]
+ gcobol cobol.dg/group2/ADD_SUBTRACT_CORR_mixed_fix___float.cob -wrapper
valgrind,-q
==1968024== Conditional jump or move depends on uninitialised value(s)
==1968024==at 0x69BE093: UnknownInlinedFun (scan.l:1667)
==1968024==by 0x69BE093: UnknownInlinedFun (stl_algo.h:4265)
==1968024==by 0x69BE093: lexer() (scan.l:1665)
==1968024==by 0x69DDB4D: UnknownInlinedFun (scan_post.h:240)
==1968024==by 0x69DDB4D: prelex() (scan_post.h:251)
==1968024==by 0x69DEC07: UnknownInlinedFun (scan_post.h:375)
==1968024==by 0x69DEC07: yylex() (scan_post.h:350)
==1968024==by 0x69472E7: yyparse() (parse.cc:16401)
==1968024==by 0x69AA657: UnknownInlinedFun (util.cc:2142)
==1968024==by 0x69AA657: cobol_parse_files(int, char const**)
(util.cc:2203)
==1968024==by 0x65A2974: compile_file() [clone .lto_priv.0] (toplev.cc:451)
==1968024==by 0x656FA91: UnknownInlinedFun (toplev.cc:2211)
==1968024==by 0x656FA91: toplev::main(int, char**) (toplev.cc:2374)
==1968024==by 0x656EAA9: main (main.cc:39)
==1968024==
==1968024== Use of uninitialised value of size 8
==1968024==at 0x69BE098: UnknownInlinedFun (scan.l:1673)
==1968024==by 0x69BE098: UnknownInlinedFun (stl_algo.h:4265)
==1968024==by 0x69BE098: lexer() (scan.l:1665)
==1968024==by 0x69DDB4D: UnknownInlinedFun (scan_post.h:240)
==1968024==by 0x69DDB4D: prelex() (scan_post.h:251)
==1968024==by 0x69DEC07: UnknownInlinedFun (scan_post.h:375)
==1968024==by 0x69DEC07: yylex() (scan_post.h:350)
==1968024==by 0x69472E7: yyparse() (parse.cc:16401)
==1968024==by 0x69AA657: UnknownInlinedFun (util.cc:2142)
==1968024==by 0x69AA657: cobol_parse_files(int, char const**)
(util.cc:2203)
==1968024==by 0x65A2974: compile_file() [clone .lto_priv.0] (toplev.cc:451)
==1968024==by 0x656FA91: UnknownInlinedFun (toplev.cc:2211)
==1968024==by 0x656FA91: toplev::main(int, char**) (toplev.cc:2374)
==1968024==by 0x656EAA9: main (main.cc:39)
==1968024==
```
and
```
+ gcobol cobol.dg/group2/ALLOCATE_Rule_8_OPTION_INITIALIZE_with_figconst.cob
-wrapper valgrind,-q
==2025703== Syscall param msync(start) points to uninitialised byte(s)
==2025703==at 0x932FB15: msync (msync.c:25)
==2025703==by 0x699F48B: symbol_table_extend() (symbols.cc:153)
==2025703==by 0x69A6B45: symbol_field_add(unsigned long, cbl_field_t*)
(symbols.cc:2591)
==2025703==by 0x68E5D9D: field_add(YYLTYPE const&, cbl_field_t*) [clone
.lto_priv.0] (parse_ante.h:2928)
==2025703==by 0x694B0A9: yyparse() (parse.y:3316)
==2025703==by 0x69AA657: UnknownInlinedFun (util.cc:2142)
==2025703==by 0x69AA657: cobol_parse_files(int, char const**)
(util.cc:2203)
==2025703==by 0x65A2974: compile_file() [clone .lto_priv.0] (toplev.cc:451)
==2025703==by 0x656FA91: UnknownInlinedFun (toplev.cc:2211)
==2025703==by 0x656FA91: toplev::main(int, char**) (toplev.cc:2374)
==2025703==by 0x656EAA9: main (main.cc:39)
==2025703== Address 0x8b9289c is in a rw- mapped file /tmp/#59860 (deleted)
segment
==2025703==
```
[Bug target/120245] New: RISC-V: Avoid FRM read/writes in non FRM related code paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120245
Bug ID: 120245
Summary: RISC-V: Avoid FRM read/writes in non FRM related code
paths
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: vineetg at gcc dot gnu.org
Reporter: vineetg at gcc dot gnu.org
CC: jeffreyalaw at gmail dot com, pan2.li at intel dot com,
rdapp at gcc dot gnu.org
Target Milestone: ---
For a function which needs FRM save/restore (say due to static rounding mode
setting), RISC-V frm mode switching backend generates FRM read/writes in all
the code paths, even those which don't deal with RM at all.
e.g. gcc/testsuite/gcc.target/riscv/rvv/autovec/unop/math-ceil-0.c
-O3 -march=rv64gcv_zvfh -mabi=lp64d -ffast-math -ftree-vectorize
void test__Float16___builtin_ceilf16 (_Float16 *out, _Float16 *in, unsigned
count)
{
for (unsigned i = 0; i < count; i++)
out[i] = __builtin_ceilf16 (in[i]);
}
test__Float16___builtin_ceilf16:
.LFB2:
frrma3 # backup RM (backup reg)
beq a2,zero,.L14
bleua5,a4,.L3
fsrmi 3# static RM
.L4:
vfcvt.x.f.v v3,v2,v0.t # Uses static RM
vfcvt.f.x.v v1,v3,v0.t # Uses static RM
vfsgnj.vv v1,v1,v2
bne a2,zero,.L4
fsrma3 # Restore OK
ld ra,24(sp)
ld s0,16(sp)
ld s1,8(sp)
addisp,sp,32
jr ra
.L3:
.L6:
callceilf16
frrma3
bne s0,s2,.L6
fsrma3 # Restore needless
jr ra
.L14:
fsrma3 # Restore Needless
ret
the frm state machine has a "sticky" note of static mode even been set and if
so, around function calls, it generates the save/restore even if that code path
doesn't need to.
FWIW The sticky static mode is needed for different reasons (see
gcc/testsuite/gcc.target/riscv/rvv/base/float-point-dynamic-frm-74.c)
Anyhow, if we can delay the intial FRM save to right before actual static RM
(that makes the backup reg live only on needed edges) and at time of restore
check if the edge for insertion has backup reg live - only then insert it.
[Bug target/120245] RISC-V: Avoid FRM read/writes in non FRM related code paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120245 --- Comment #1 from Vineet Gupta --- Or maybe instead of tracking the backup reg, track the FRM itself. It seems to be a hard reg so live tracking is easier.
[Bug tree-optimization/111415] [12/13/14 Regression] False positive array-bounds warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111415
stephematician changed:
What|Removed |Added
CC||stephematician.acct@proton.
||me
--- Comment #3 from stephematician ---
I encountered what I believe is the same bug while compiling an R package for
CRAN.
I reduced the code to the following example which produces errors on 12.4,
13.1-13.3, 14.1-14.2.
An array-bounds warning occurs with -O1, -O2, and -O3, but not with -Os.
Compiled with flags: -fpic -std=c++20 -Wall
#include
#include
inline std::vector adjust_pvalues(const std::vector &
unadjusted) {
const size_t n_pvalue = unadjusted.size();
if (n_pvalue < 2) return unadjusted;
/* Include this line and -O1 thru to -O3 give warnings */
const std::vector index(n_pvalue);
/* NOTE: Can eliminate warning by removing second argument */
std::vector adjusted(n_pvalue, 0.0);
return adjusted;
}
int main(int argc, char ** argv) {
std::vector x(2);
x = adjust_pvalues(x);
return 0;
}
The above snippet is currently available on godbolt:
https://godbolt.org/z/38nnaEcrf
[Bug other/116792] RFE: should we be able to generate diagnostics in HTML format?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116792 --- Comment #8 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:e4ccad8faf5266248993f7896b000ccf871ded30 commit r16-579-ge4ccad8faf5266248993f7896b000ccf871ded30 Author: David Malcolm Date: Mon May 12 21:45:36 2025 -0400 diagnostics: improvements to experimental-html output [PR116792] Add barebones support for * diagnostic metadata rules * quoted source * generated patches * execution paths gcc/ChangeLog: PR other/116792 * diagnostic-format-html.cc: Include "diagnostic-format-text.h", "pretty-print-urlifier.h" and "edit-context.h". (html_builder::html_builder): Fix indentation in decl. (html_builder::make_element_for_diagnostic): Split out metadata code into make_element_for_metadata. Call make_element_for_source, make_element_for_path, and make_element_for_patch. (html_builder::make_element_for_source): New. (html_builder::make_element_for_path): New. (html_builder::make_element_for_patch): New. (html_builder::make_metadata_element): New. (html_builder::make_element_for_metadata): New. (html_output_format::get_builder): New. (selftest::test_html_diagnostic_context::get_builder): New. (selftest::test_simple_log): Update test to print a quoted string, and verify that it uses a "gcc-quoted-text" span. (selftest::test_metadata): New. (selftest::diagnostic_format_html_cc_tests): Call it. gcc/testsuite/ChangeLog: PR other/116792 * gcc.dg/html-output/missing-semicolon.py: Verify that we don't have an empty "gcc-annotated-source" and we do have a "gcc-generated-patch". * gcc.dg/plugin/diagnostic-test-metadata-html.c: New test. * gcc.dg/plugin/diagnostic-test-metadata-html.py: New test script. * gcc.dg/plugin/diagnostic-test-paths-2.c: Add "-fdiagnostics-add-output=experimental-html" to options. Add invocation of diagnostic-test-paths-2.py. * gcc.dg/plugin/diagnostic-test-paths-2.py: New test script. * gcc.dg/plugin/plugin.exp (plugin_test_list): Add diagnostic-test-metadata-html.c. Signed-off-by: David Malcolm
[Bug c/118868] __builtin_assoc_barrier with pointers cause ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118868 --- Comment #5 from Andrew Pinski --- Created attachment 61411 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61411&action=edit testcase
[Bug c/118868] __builtin_assoc_barrier with pointers cause ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118868
--- Comment #6 from Andrew Pinski ---
Reduced testcase:
void *f(void *a) { return __builtin_assoc_barrier(a); }
[Bug c/120246] New: ICE: tree check: expected class type, have exceptional (error_mark) in fold_const_call_1, at fold-const-call.cc:1569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120246
Bug ID: 120246
Summary: ICE: tree check: expected class type, have exceptional
(error_mark) in fold_const_call_1, at
fold-const-call.cc:1569
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rundongyang22 at m dot fudan.edu.cn
Target Milestone: ---
Created attachment 61410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61410&action=edit
The preprocessed source(with -save-temp)
# gcc Version & System Type & Configure Option
$ $CC -v
Using built-in specs.
COLLECT_GCC=/home/liuyu/Desktop/gcc-13/bin/gcc
COLLECT_LTO_WRAPPER=/home/liuyu/Desktop/gcc-13/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --enable-languages=c,c++
--prefix=/home/liuyu/Desktop/bin
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (GCC)
# Compiler Output
$CC -save-temps 2042.c
2042.c:11:1: warning: ‘const’ attribute on function returning ‘void’
[-Wattributes]
11 | __attribute__((const)) void print_args(const char *format, ...) {
| ^
2042.c: In function ‘print_args’:
2042.c:30:28: error: conflicting types for ‘num’; have ‘double’
30 | double num = va_arg(args, double);
|^~~
2042.c:25:25: note: previous definition of ‘num’ with type ‘int’
25 | int num = va_arg(args, int);
| ^~~
2042.c:26:21: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in fold_const_call_1, at fold-const-call.cc:1569
26 | printf("%d", num);
| ^
0x19dcb2a tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.cc:8931
0xc3ae27 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:3663
0x10da774 fold_const_call_1
../../gcc/fold-const-call.cc:1569
0x10db6f2 fold_const_call(combined_fn, tree_node*, tree_node*, tree_node*)
../../gcc/fold-const-call.cc:1745
0xe55af6 fold_builtin_2
../../gcc/builtins.cc:9785
0xe5616f fold_builtin_n
../../gcc/builtins.cc:9949
0xe56813 fold_call_expr(unsigned int, tree_node*, bool)
../../gcc/builtins.cc:10047
0x1182954 gimplify_call_expr
../../gcc/gimplify.cc:3684
0x11bc932 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16348
0x118fbbc gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7219
0x117d35e gimplify_statement_list
../../gcc/gimplify.cc:2019
0x11be993 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16821
0x118fbbc gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7219
0x117b13a gimplify_bind_expr
../../gcc/gimplify.cc:1430
0x11bd7ec gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16577
0x118fbbc gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7219
0x117d35e gimplify_statement_list
../../gcc/gimplify.cc:2019
0x11be993 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16821
0x118fbbc gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7219
0x117f0c2 gimplify_switch_expr
../../gcc/gimplify.cc:2716
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/118868] __builtin_assoc_barrier with pointers cause ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118868 --- Comment #7 from Andrew Pinski --- Created attachment 61412 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61412&action=edit Patch which I am testing for this This patch just fixes pointer types. The others will be fixed seperately because those require some front-end changes.
[Bug tree-optimization/120069] [16 Regression] Yes another imagick -march=native -flto -Ofast + PGO regression between g:1c0cbc1b300e08df5ebfce00a7195890d78f2064 and g:55b01e17c793688a2878fa43a76df126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120069 --- Comment #8 from Jan Hubicka --- In some graphs we are now better than before, mostly due to the inlining change g:064cac730f88dc71c6da578f9ae5b8e092ab6cd4 which enables inlining on non-hot edges if callee speeds up enoug. This improved imagick and x264 with PGO, but that is independent issue. I think there are two imagick PGO regressions. One already solved caused by stv and -Os costing and other one that needs to be analyzed. So bisecting would be useful.
[Bug analyzer/120213] analyzer report a false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120213 --- Comment #9 from Raffaello Bertini --- (In reply to David Malcolm from comment #8) > I'm not sure I fully grok the example code, but FWIW the analyzer doesn't > yet "know" about the behavior of strnlen and so conservatively assumes any > possible size_t value as the output. There are also limitations in the > current internal representation that prevent various useful reasoning about > string operations, so it might be running into that. I see. That make sense, as it has esplicitly shown the path with the input string "H" it might even not look correct, or over-analyzing the code. Beside the analyzer output is always the same independently of the input string and that's correct. but yeah it looks like it is failing to understand that at some point the recursion will return the 'l' var < NUM_CHARS and won't go to read outside the stack. Basically is following the 'true branch' assuming l > NUM_CHARS when effectively l is <= NUM_CHARS. Btw at the moment the only way to "fix it" is to wrap the function in pragmas to ignore the analyzer warning? or there are some extra directive to help the analyzer "understand" the code?
[Bug target/120186] [pa] internal compiler error: in fail, at selftest.cc:47 during bootstrap with LRA enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120186 --- Comment #7 from John David Anglin --- I don't think I've ever done a LRA build with selftests enabled.
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 --- Comment #20 from Tobias Burnus --- And for the condition, I think the proper way is to write: #if MPFR_VERSION >= MPFR_VERSION_NUM(4,2,0) ... = mpfr_sinpi ( ... ) #else fallback #endif
[Bug cobol/119377] cobol.dg/group1/declarative_1.cob fails (segfaults, uninitialised vars)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377 --- Comment #15 from Robert Dubner --- Oh. Well, that's a comedown. I am compiling GCC-16 on an Ubuntu 22.04 LTS system, with the Ubuntu distribution version of GCC-11. When I build GCC-6 and run "make check-cobol" I am getting, as of today, === cobol Summary === # of expected passes5466 # of expected failures 54 /home/bob/repos/gcc-cobol/build/gcc/gcobol version 16.0.0 20250511 (experimental) (GCOBOL(debuggable)-16.20250510-fcb1be-ubu22) Sigh. "My lightbulb is working fine..."
[Bug cobol/119377] cobol.dg/group1/declarative_1.cob fails (segfaults, uninitialised vars)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377 --- Comment #16 from Robert Dubner --- (In reply to Iain Sandoe from comment #10) > (In reply to Robert Dubner from comment #9) > > Whether or not this will fix any other problems, I don't know. I do know > > that valgrind was reporting uninitialized data, and now it is not. > > sadly, it does not fix the underlying issue: > > I built and tested r16-528-gd7d24f9cc55d5cf0a70a984d4e63e8a307710d9e > > There are still 90 FAILs on x86_64 darwin all of this same form. > > /src-local/gcc-master/gcc/testsuite/cobol.dg/group1/declarative_1.cob:51:22: > sorry, unimplemented: SECTION segment was ignored > > (that's an empty string - which shows as two spaces) Iain, I tried doing the obvious thing; downloaded the repository on a Darwin system, installed GMP and MPFR and MPC, did a configure. It fails a little way into the build with *** Configuration aarch64-apple-darwin24.3 not supported Hints?
[Bug c/120248] ICE: Segmentation fault at gcc/toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120248 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup, already fixed in gcc 15. *** This bug has been marked as a duplicate of bug 98195 ***
[Bug c/98195] ICE after `void value not ignored as it ought to be` error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98195 Andrew Pinski changed: What|Removed |Added CC||rundongyang22 at m dot fudan.edu.c ||n --- Comment #12 from Andrew Pinski --- *** Bug 120248 has been marked as a duplicate of this bug. ***
