[Bug testsuite/120251] cobol tests depend on locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120251 --- Comment #3 from GCC Commits --- The master branch has been updated by Robert Dubner : https://gcc.gnu.org/g:022d8e25e49021b378a4e6c24c2f0c380a066690 commit r16-660-g022d8e25e49021b378a4e6c24c2f0c380a066690 Author: Robert Dubner Date: Thu May 15 12:01:12 2025 -0400 cobol: Don't display 0xFF HIGH-VALUE characters in testcases. [PR120251] The tests were displaying 0xFF characters, and the resulting generated output changed with the system locale. The check_88 test was modified so that the regex comparisons ignore those character positions. Two of the other tests were changed to output hexadecimal rather than character strings. There is one new test, and the other inspect testcases were edited to remove an unimportant back-apostrophe that had found its way into the source code sequence number area. gcc/testsuite/ChangeLog: PR cobol/120251 * cobol.dg/group1/check_88.cob: Ignore characters above 0x80. * cobol.dg/group2/ALLOCATE_Rule_8_OPTION_INITIALIZE_with_figconst.cob: Output HIGH-VALUE as hex, rather than as characters. * cobol.dg/group2/ALLOCATE_Rule_8_OPTION_INITIALIZE_with_figconst.out: Likewise. * cobol.dg/group2/INSPECT_CONVERTING_TO_figurative_constants.cob: Typo. * cobol.dg/group2/INSPECT_CONVERTING_TO_figurative_constants.out: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_1.cob: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_2.cob: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_3.cob: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_4.cob: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_5-f.cob: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_6.cob: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_7.cob: Likewise. * cobol.dg/group2/Multiple_INDEXED_BY_variables_with_the_same_name.cob: New test. * cobol.dg/group2/Multiple_INDEXED_BY_variables_with_the_same_name.out: New test.
[Bug fortran/119812] Bogus rank and type mismatch errors with procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119812 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Keywords||rejects-valid Status|UNCONFIRMED |RESOLVED --- Comment #1 from anlauf at gcc dot gnu.org --- See also pr119812, where this has been fixed. *** This bug has been marked as a duplicate of bug 119928 ***
[Bug fortran/119928] [15/16 Regression] Bogus "Interface mismatch" in gfortran.dg/proc_ptr_52.f90 with -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119928 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||abensonca at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- *** Bug 119812 has been marked as a duplicate of this bug. ***
[Bug ipa/120295] [15/16 Regression] Wrong code on -O3 for trunk version (live code is wrongly eliminated)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120295 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-05-15 Keywords||needs-bisection Status|UNCONFIRMED |NEW
[Bug ipa/120295] [15/16 Regression] Wrong code on -O3 for trunk version (live code is wrongly eliminated)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120295 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #4 from mcccs at gmx dot com --- (can't bisect, because) not reproducible on aarch64
[Bug tree-optimization/116546] Missed optimization of redundant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116546 --- Comment #3 from GCC Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:65cd212bd4c533351a09e6974f40ae5d7effca84 commit r16-663-g65cd212bd4c533351a09e6974f40ae5d7effca84 Author: Andrew MacLeod Date: Wed May 14 11:12:22 2025 -0400 Improve constant bitmasks. bitmasks for constants are created only for trailing zeros. It is no additional work to also include leading 1's in the value that are also known. before : [5, 7] mask 0x7 value 0x0 after : [5, 7] mask 0x3 value 0x4 PR tree-optimization/116546 * value-range.cc (irange_bitmask::irange_bitmask): Include leading ones in the bitmask.
[Bug tree-optimization/116546] Missed optimization of redundant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116546 --- Comment #5 from GCC Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:ac55655ce45a237a6a01e0cce50211841603c2ec commit r16-665-gac55655ce45a237a6a01e0cce50211841603c2ec Author: Andrew MacLeod Date: Wed May 14 11:32:58 2025 -0400 Enhance bitwise_and::op1_range Any known bits from the LHS range can be used to specify known bits in the non-mask operand. PR tree-optimization/116546 gcc/ * range-op.cc (operator_bitwise_and::op1_range): Utilize bitmask from the LHS to improve op1's bitmask. gcc/testsuite/ * gcc.dg/pr116546.c: New.
[Bug tree-optimization/116546] Missed optimization of redundant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116546 --- Comment #4 from GCC Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:b3327649bffd32af962662dce054b94be2d7330d commit r16-664-gb3327649bffd32af962662dce054b94be2d7330d Author: Andrew MacLeod Date: Wed May 14 11:13:15 2025 -0400 Allow bitmask intersection to process unknown masks. bitmask_intersection should not return immediately if the current mask is unknown. Unknown may mean its the default for a range, and this may interact in intersting ways with the other bitmask. PR tree-optimization/116546 * value-range.cc (irange::intersect_bitmask): Allow unknown bitmasks to be processed.
[Bug testsuite/120251] cobol tests depend on locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120251 Robert Dubner changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot gnu.org
[Bug c++/120285] [14/15/16 Regression] ice in digest_init_r, at cp/typeck2.cc:1397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120285 Marek Polacek changed: What|Removed |Added Priority|P3 |P2 Keywords|needs-bisection |ice-on-valid-code Summary|ice in digest_init_r, at|[14/15/16 Regression] ice |cp/typeck2.cc:1397 |in digest_init_r, at ||cp/typeck2.cc:1397 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |14.3 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug tree-optimization/116546] Missed optimization of redundant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116546 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |16.0
[Bug c++/120289] internal compiler error: tree check: accessed elt 2 of 'tree_vec' with 1 elts in tsubst, at cp/pt.cc:16650 since 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120289 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #1 from mcccs at gmx dot com --- Created attachment 61432 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61432&action=edit preprocessed.cpp
[Bug middle-end/120290] internal compiler error: in expand_asm_stmt, at cfgexpand.cc:3720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120290
--- Comment #1 from Andrew Pinski ---
Reduced:
```
void f(int k){
asm("" : " =r" (k) : "0" (k));
}
```
The space in the output constraint is invalid and is causing the issue.
[Bug cobol/119632] section segments (cobol85) not implemented, "ignored" -> raising compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632 --- Comment #7 from Simon Sobisch --- I think https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/commit/9c2fcd3606662e550aea6173b06bc2a500b2ac52 is the right approach (adding a warning later, syntax-check if not iso, otherwise abort). But it should really do that - and allow it for _any_ other standard, not only ibm.
[Bug tree-optimization/120277] [16 Regression] Crash at -O2: in upper_bound, at value-range.h:1181 since r16-577-gc40a4cc2d943d8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120277 --- Comment #3 from GCC Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:4291071a6aa3b50800ad5fc70b5fb83cb9398237 commit r16-661-g4291071a6aa3b50800ad5fc70b5fb83cb9398237 Author: Andrew MacLeod Date: Thu May 15 11:06:05 2025 -0400 Check for casts becoming UNDEFINED. In various situations a cast that is ultimately unreahcable may produce an UNDEFINED result, and we can't check the bounds in this case. PR tree-optimization/120277 gcc/ * range-op-ptr.cc (operator_cast::fold_range): Check if the cast if UNDEFINED before setting bounds. gcc/testsuite/ * gcc.dg/pr120277.c: New.
[Bug middle-end/120278] [12/13/14/15 Regression] Switch expansion generates extra compares with -fno-jump-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278 --- Comment #8 from Ken Young --- It seems to me that even if a naive decision tree is to be generated, it could be done in a manner that simply checks for the case being equal and not do anything with greater than From: .L9: cmpl $4, -4(%rbp) je .L2 cmpl $4, -4(%rbp) jg .L3 cmpl $3, -4(%rbp) je .L4 cmpl $3, -4(%rbp) jg .L3- already checked for ==4, >4, ==3 so >3 will always be false cmpl $2, -4(%rbp) je .L5 cmpl $2, -4(%rbp) jg .L3- already checked for ==4, >4, ==3, ==2 so >2 will always be false cmpl $0, -4(%rbp) je .L6 cmpl $1, -4(%rbp) je .L7 jmp .L3 To: .L9: cmpl $4, -4(%rbp) je .L2 cmpl $3, -4(%rbp) je .L4 cmpl $2, -4(%rbp) je .L5 cmpl $0, -4(%rbp) je .L6 cmpl $1, -4(%rbp) je .L7 jmp .L3
[Bug tree-optimization/116546] Missed optimization of redundant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116546 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||amacleod at redhat dot com --- Comment #6 from Andrew Macleod --- fixed.
[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 Bug 85316 depends on bug 116546, which changed state. Bug 116546 Summary: Missed optimization of redundant comparison https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116546 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/120278] [12/13/14/15 Regression] Switch expansion generates extra compares with -fno-jump-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278 --- Comment #9 from Jakub Jelinek --- If you are using -O0 for production code where performance matters, you're doing something wrong.
[Bug tree-optimization/120277] [16 Regression] Crash at -O2: in upper_bound, at value-range.h:1181 since r16-577-gc40a4cc2d943d8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120277 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Andrew Macleod --- cast needs to check that the fold call didn't produce UNDEFINED. fixed.
[Bug c++/120287] [15/16 Regression] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in is_std_substitution, at cp/mangle.cc:507 since r15-2798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120287 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.2 Summary|[15/16 Regression] internal |[15/16 Regression] internal |compiler error: tree check: |compiler error: tree check: |expected class 'type', have |expected class 'type', have |'exceptional' (error_mark) |'exceptional' (error_mark) |in is_std_substitution, at |in is_std_substitution, at |cp/mangle.cc:507|cp/mangle.cc:507 since ||r15-2798
[Bug testsuite/120251] cobol tests depend on locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120251 --- Comment #5 from GCC Commits --- The master branch has been updated by Robert Dubner : https://gcc.gnu.org/g:fae53928595341981f08ded4edcbba07ee1d5d04 commit r16-667-gfae53928595341981f08ded4edcbba07ee1d5d04 Author: Robert Dubner Date: Thu May 15 13:33:16 2025 -0400 cobol: One additional edit to testsuite/cobol.dg/group1/check_88.cob [PR120251] Missed one edit. This fixes that. gcc/testsuite/ChangeLog: PR cobol/120251 * cobol.dg/group1/check_88.cob: One final regex "." instead of "ß"
[Bug middle-end/120278] [12/13/14/15 Regression] Switch expansion generates extra compares with -fno-jump-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278 --- Comment #11 from Jakub Jelinek --- Dead branches and dead code definitely appear in -O0 code just about everywhere, that is not about correctness but about efficiency, which is a non-goal for -O0. Even at higher optimization levels compiler can't guarantee there are no dead branches or no dead code, but optimizations try hard to remove it. But when choosing -O0 you've asked the compiler to compile quickly...
[Bug c++/112410] error when auto(x) is used in a variable initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112410 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.3
[Bug c++/120287] [15/16 Regression] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in is_std_substitution, at cp/mangle.cc:507 since r15-2798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120287
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-05-15
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed. Slightly more reduced (removing some C++20 features even):
```
namespace std
{
template
auto m = []{}();
}
auto t = std::m<1>;
```
But this above one dates before GCC 15 at least back to GCC 10.
[Bug testsuite/120251] cobol tests depend on locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120251 --- Comment #6 from Robert Dubner --- And this time I figured out how to change a locale to test it.
[Bug fortran/120139] [15 Regression] -fc-prototypes emits incorrect type for arrays with variable extents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120139 --- Comment #2 from GCC Commits --- The releases/gcc-15 branch has been updated by Thomas Koenig : https://gcc.gnu.org/g:a85776f7f64271d628ae0a04f02717ee6572e6e8 commit r15-9688-ga85776f7f64271d628ae0a04f02717ee6572e6e8 Author: Thomas Koenig Date: Wed May 14 20:11:48 2025 +0200 Fix explicit arrays with non-constant size for -fc-prototypes. gcc/fortran/ChangeLog: PR fortran/120139 * dump-parse-tree.cc (get_c_type_name): If no constant size of an array exists, output an asterisk. (cherry picked from commit 4f9c7b5258f2af89bba8e954c277981d2e2ee1ef)
[Bug fortran/120107] [15 regression] -fc-prototypes for ISO_FORTRAN_ENV generates duplicate typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120107 --- Comment #4 from GCC Commits --- The releases/gcc-15 branch has been updated by Thomas Koenig : https://gcc.gnu.org/g:c6ec3a9bddb4224a2369b0284ade4b474cd4b0ce commit r15-9687-gc6ec3a9bddb4224a2369b0284ade4b474cd4b0ce Author: Thomas Koenig Date: Tue May 13 19:02:06 2025 +0200 Do not dump non-interoperable types with -fc-prototypes. gcc/fortran/ChangeLog: PR fortran/120107 * dump-parse-tree.cc (write_type): Do not dump non-interoperable types. (cherry picked from commit fa0dff8e99e81bc7a3db1dc57d4fc340e0525b1d)
[Bug fortran/120107] [15 regression] -fc-prototypes for ISO_FORTRAN_ENV generates duplicate typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120107 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Thomas Koenig --- Fixed on all affected branches, closing. Thanks a lot for the bug report!
[Bug c++/120285] [14/15/16 Regression] ice in digest_init_r, at cp/typeck2.cc:1397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120285 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2025-05-15
[Bug fortran/120139] [15 Regression] -fc-prototypes emits incorrect type for arrays with variable extents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120139 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Thomas Koenig --- Fixed on all affected branches, closing. Thanks a lot for the bug report!
[Bug middle-end/120278] [12/13/14/15 Regression] Switch expansion generates extra compares with -fno-jump-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278 --- Comment #12 from Ken Young --- For what it's worth, it has worked well for our simple bare metal ARM applications written in C and this is the first instance where the generated object code did extra things that were not expected.
[Bug c++/120291] internal compiler error: in tsubst_pack_expansion, at cp/pt.cc:13941 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120291 --- Comment #1 from mcccs at gmx dot com --- r12-5952-g561414cdf8ef0d
[Bug middle-end/120278] [12/13/14/15 Regression] Switch expansion generates extra compares with -fno-jump-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278 --- Comment #10 from Ken Young --- "Correctness" (no dead code, no dead branches) matters more than performance in this instance.
[Bug c++/120287] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in is_std_substitution, at cp/mangle.cc:507
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120287 --- Comment #3 from Jakub Jelinek --- With -std=c++0x #c1 ICEs starting with r5-2991-g5e0231c231404677aa1b9
[Bug c++/120287] [12/13/14/15/16 Regression] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in is_std_substitution, at cp/mangle.cc:507
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120287 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.5 Keywords|needs-bisection | Summary|internal compiler error:|[12/13/14/15/16 Regression] |tree check: expected class |internal compiler error: |'type', have 'exceptional' |tree check: expected class |(error_mark) in |'type', have 'exceptional' |is_std_substitution, at |(error_mark) in |cp/mangle.cc:507|is_std_substitution, at ||cp/mangle.cc:507 --- Comment #4 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #3) > With -std=c++0x #c1 ICEs starting with r5-2991-g5e0231c231404677aa1b9 So basically since template variable support was added.
[Bug c++/120287] [12/13/14/15/16 Regression] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in is_std_substitution, at cp/mangle.cc:507
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120287 --- Comment #5 from Jakub Jelinek --- And with s/auto/constexpr auto/g after even more errors ICEs starting with r5-2539-g4a4f287dc1ae6f111b28e
[Bug c++/120287] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in is_std_substitution, at cp/mangle.cc:507
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120287
Andrew Pinski changed:
What|Removed |Added
Target Milestone|15.2|---
Keywords||ice-checking,
||needs-bisection
Known to fail||10.3.0
Summary|[15/16 Regression] internal |internal compiler error:
|compiler error: tree check: |tree check: expected class
|expected class 'type', have |'type', have 'exceptional'
|'exceptional' (error_mark) |(error_mark) in
|in is_std_substitution, at |is_std_substitution, at
|cp/mangle.cc:507 since |cp/mangle.cc:507
|r15-2798|
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Confirmed. Slightly more reduced (removing some C++20 features even):
> ```
> namespace std
> {
> template
> auto m = []{}();
> }
> auto t = std::m<1>;
> ```
>
> But this above one dates before GCC 15 at least back to GCC 10.
Oh I see what is the difference between the testcases in comment #1 and comment
#0, const.
r15-2798 changed: `Linkage of const-qualified variable template` which exposed
the latent bug by causing the mangling code to happen. It would be useful to
get a new bisect based on the testcase in comment #1.
[Bug target/120297] New: [16 Regression] RISC-V: Miscompile at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297
Bug ID: 120297
Summary: [16 Regression] RISC-V: Miscompile at -O3
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:
unsigned a;
short c;
char d;
unsigned long e;
_Bool f[10][10];
unsigned g[10];
long long ak;
char i = 7;
long long t[10];
short x[10][10][10][10];
short y[10][10][10][10];
void h(char i, long long t[], short x[][10][10][10], short y[][10][10][10],
_Bool aa) {
for (int j = 2; j < 8; j += 2) {
for (short k = 0; k < 10; k++) {
for (int l = 3; l < 8; l += 2)
a = x[1][j][k][l];
c = x[c][1][1][c];
}
for (int k = 0; k < 10; k++) {
f[2][k] |= (_Bool)t[c];
g[c] = t[c + 1];
d += y[j][1][k][k];
e = e > i ? e : i;
}
}
}
int main() {
t[c] = 1;
h(i, t, x, y, a);
for (int j = 0; j < 10; ++j)
for (int k = 0; k < 10; ++k)
ak ^= f[j][k] + 238516665 + (ak >> 2);
ak ^= g[c] + 238516665 + (ak >> 2);
__builtin_printf("%llu\n", ak);
}
Commands:
# -O3
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64gcv -flto -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
> 1
234635117
# -O2
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64gcv -flto -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
> 1
234635118
Bisected to r15-6657-g405c99c1721 as first bad commit
Tried manually reducing testcase more but failed to reproduce the error when
doing so.
Found via fuzzer
[Bug go/118286] go crypto/tls test fails because of expired certificate? (TestVerifyConnection, bad certificate)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118286 --- Comment #6 from GCC Commits --- The releases/gcc-12 branch has been updated by Sam James : https://gcc.gnu.org/g:b1c65033b01d43d36b5b7f3713b6e409792bd51c commit r12-11099-gb1c65033b01d43d36b5b7f3713b6e409792bd51c Author: Ian Lance Taylor Date: Sat Jan 4 15:54:58 2025 -0800 crypto/tls: fix Config.Time in tests using expired certificates This is a backport of https://go.dev/cl/640237 from the main repo. Fixes PR go/118286 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/640435 (cherry picked from commit ed1493e12ed75e837e9b9aa794ed24daf397df7c)
[Bug go/118286] go crypto/tls test fails because of expired certificate? (TestVerifyConnection, bad certificate)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118286 --- Comment #8 from GCC Commits --- The releases/gcc-14 branch has been updated by Sam James : https://gcc.gnu.org/g:ebef63ee3a34475ec224ddf0fbc64ccb31033d8d commit r14-11786-gebef63ee3a34475ec224ddf0fbc64ccb31033d8d Author: Ian Lance Taylor Date: Sat Jan 4 15:54:58 2025 -0800 crypto/tls: fix Config.Time in tests using expired certificates This is a backport of https://go.dev/cl/640237 from the main repo. Fixes PR go/118286 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/640435 (cherry picked from commit ed1493e12ed75e837e9b9aa794ed24daf397df7c)
[Bug go/118286] go crypto/tls test fails because of expired certificate? (TestVerifyConnection, bad certificate)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118286 --- Comment #7 from GCC Commits --- The releases/gcc-13 branch has been updated by Sam James : https://gcc.gnu.org/g:9ad74a57904744418a7319a492a698ddbfb787ca commit r13-9658-g9ad74a57904744418a7319a492a698ddbfb787ca Author: Ian Lance Taylor Date: Sat Jan 4 15:54:58 2025 -0800 crypto/tls: fix Config.Time in tests using expired certificates This is a backport of https://go.dev/cl/640237 from the main repo. Fixes PR go/118286 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/640435 (cherry picked from commit ed1493e12ed75e837e9b9aa794ed24daf397df7c)
[Bug go/118286] go crypto/tls test fails because of expired certificate? (TestVerifyConnection, bad certificate)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118286 Sam James changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Known to work||12.4.1, 13.3.1, 14.2.1, ||15.0 --- Comment #9 from Sam James --- (In reply to Ian Lance Taylor from comment #4) > If you have the time, please go ahead and do the backports. Thanks. (In reply to Sam James from comment #5) > Thanks. I'll get to it but I won't promise to immediately. Done. Thanks.
[Bug tree-optimization/93271] [12/13/14 regression] SRA producing wrong code on denormals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #21 from Jakub Jelinek --- Martin, could we backport r15-3070 to 14.3?
[Bug tree-optimization/120277] [16 Regression] Crash at -O2: in upper_bound, at value-range.h:1181 since r16-577-gc40a4cc2d943d8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120277 Sam James changed: What|Removed |Added Summary|[16 Regression] Crash at|[16 Regression] Crash at |-O2: in upper_bound, at |-O2: in upper_bound, at |value-range.h:1181 |value-range.h:1181 since ||r16-577-gc40a4cc2d943d8 Keywords|needs-bisection | CC||amacleod at redhat dot com --- Comment #2 from Sam James --- (In reply to Yunbo Ni from comment #0) > Bisected to > https://github.com/gcc-mirror/gcc/commit/ > c40a4cc2d943d8572a62f21d3eb1d4171e51d5ac r16-577-gc40a4cc2d943d8
[Bug tree-optimization/93271] [12/13/14 regression] SRA producing wrong code on denormals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271 --- Comment #22 from Martin Jambor --- (In reply to Jakub Jelinek from comment #21) > Martin, could we backport r15-3070 to 14.3? It depends on r15-2476-gb3974356b0981c which, IIRC, Richi was not planning to backport.
[Bug c++/120287] New: [15/16 Regression] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in is_std_substitution, at cp/mangle.cc:507
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120287
Bug ID: 120287
Summary: [15/16 Regression] internal compiler error: tree
check: expected class 'type', have 'exceptional'
(error_mark) in is_std_substitution, at
cp/mangle.cc:507
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Starting with r15-2798-g82cd63a63eaa61 we ICE after giving the expected error:
namespace std
{
template
constexpr auto format_kind = []{ static_assert(false); }();
}
template struct S { };
S> s;
Bad: 8742 /home/remote/jwakely/gcc-bisect-objs/cc1plus.r15-2798
ice.cc: In instantiation of 'constexpr const auto std::format_kind':
ice.cc:7:8: required from here
7 | S> s;
|^~
ice.cc:4:48: error: static assertion failed
4 | constexpr auto format_kind = []{ static_assert(false); }();
|^
ice.cc:4:48: note: 'false' evaluates to false
ice.cc:4:16: error: deduced type 'const void' for 'std::format_kind' is incomplete
4 | constexpr auto format_kind = []{ static_assert(false); }();
|^~~
ice.cc:4:30: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in is_std_substitution, at cp/mangle.cc:508
4 | constexpr auto format_kind = []{ static_assert(false); }();
| ^
0x2e2f7ea internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:491
0x159a2b8 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.cc:9051
0x408f48 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:3787
0x5f696b is_std_substitution
../../gcc/cp/mangle.cc:508
0x5f705d find_substitution
../../gcc/cp/mangle.cc:640
0x5fb066 write_prefix
../../gcc/cp/mangle.cc:1310
0x5fb53e write_prefix
../../gcc/cp/mangle.cc:1362
0x5faf90 write_nested_name
../../gcc/cp/mangle.cc:1279
0x5fa517 write_name
../../gcc/cp/mangle.cc:1171
0x5f92ff write_encoding
../../gcc/cp/mangle.cc:938
0x5f8417 write_mangled_name
../../gcc/cp/mangle.cc:820
0x60dfc2 mangle_decl_string
../../gcc/cp/mangle.cc:4421
0x60e012 get_mangled_id
../../gcc/cp/mangle.cc:4442
0x60e350 mangle_decl(tree_node*)
../../gcc/cp/mangle.cc:4480
0x157a585 decl_assembler_name(tree_node*)
../../gcc/tree.cc:725
0xa6487d symtab_node::get_comdat_group_id()
../../gcc/cgraph.h:258
0xa84f49 analyze_functions
../../gcc/cgraphunit.cc:1203
0xa8860f symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2560
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/120190] Definition of the primary template of std::format_kind seems IFNDR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120190 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug fortran/120286] New: [OpenMP] Double free detected when using openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120286 Bug ID: 120286 Summary: [OpenMP] Double free detected when using openmp Product: gcc Version: 15.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: itou.tetsuya at fujitsu dot com Target Milestone: --- The following program terminated with SIGSEGV. This does not occur in gfortran-11 and earlier versions, but seems to occur in gfortran-12 and later versions. It also did not occur with flang or ifort. This does not occur if -fopenmp is not specified. --- program main implicit none type fooPtr_t class(foo_t), pointer :: p end type fooPtr_t type fooPtrStack_t class(fooPtr_t), allocatable :: list(:) end type fooPtrStack_t type foo_t integer :: dummy end type foo_t type(fooPtrStack_t) :: x class(foo_t), pointer :: ptr integer it, itmax, n, nmax nmax = 1 allocate(x%list(nmax)) allocate(x%list(nmax)%p) itmax = 32 do it = 1, itmax !$omp parallel do default(none) private(n,ptr) shared(nmax,x) do n = 1, nmax ptr => x%list(n)%p end do end do write(*,'(a)') 'done' end program main --- Results for 11.4 and 15.1: https://godbolt.org/z/6f9KvG1av
[Bug rtl-optimization/120284] inline assembly operand constraint not comply with document
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120284
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
(In reply to Huiba Li from comment #3)
> And actually, I don't need the input register to be the same as the output
> register. All I need here is making x both input and output to the assembly.
> So in theory, should it also be OK to write ```asm volatile("" : "=r"(x) :
> "r"(x))```?
In that case you need to use "movq %1, %0" in the asm to actually copy the
value, because the constraints don't guarantee it is the same register, it can
very well be a different one.
By using "0" or "+r" you require that the input and output use the same
register and so don't need to copy anything.
[Bug libstdc++/120288] [15/16 regression] spurious null pointer dereference in std::__detail::_Hashtable_base::_M_key_equals since gcc-15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120288 Sam James changed: What|Removed |Added Component|c++ |libstdc++ Summary|spurious null pointer |[15/16 regression] spurious |dereference in |null pointer dereference in |std::__detail::_Hashtable_b |std::__detail::_Hashtable_b |ase::_M_key_equals since|ase::_M_key_equals since |gcc-15 |gcc-15 Target Milestone|--- |15.2 Keywords||diagnostic, false-positive --- Comment #1 from Sam James --- (I doubt it is a libstdc++ issue, but just putting it there to start with.)
[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
Thomas Schwinge changed:
What|Removed |Added
Resolution|FIXED |---
CC||tschwinge at gcc dot gnu.org
Status|RESOLVED|REOPENED
--- Comment #8 from Thomas Schwinge ---
(In reply to GCC Commits from comment #6)
> commit r16-537-g3e2b83faeb6b14254641933525e63171e89d973f
> libstdc++: Make dg-require-namedlocale work for more targets [PR65909]
With this, I see:
[-PASS:-]{+UNSUPPORTED:+} 22_locale/locale/cons/12352.cc
-std=gnu++17[-(test for excess errors)-]
[-PASS: 22_locale/locale/cons/12352.cc -std=gnu++17 execution test-]
[-PASS: 22_locale/locale/cons/12438.cc -std=gnu++17 (test for warnings,
line 48)-]
[-PASS: 22_locale/locale/cons/12438.cc -std=gnu++17 (test for excess
errors)-]
[-PASS:-]{+UNSUPPORTED:+} 22_locale/locale/cons/12438.cc
-std=gnu++17[-execution test-]
[-PASS:-]{+UNSUPPORTED:+} 22_locale/locale/cons/7222-env.cc
-std=gnu++17[-(test for excess errors)-]
[-PASS: 22_locale/locale/cons/7222-env.cc -std=gnu++17 execution test-]
These are exactly the test cases that 'dg-require-namedlocale ""', which now
fails:
locale '{}' not supported
I suppose that's in error?
[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|RESOLVED|REOPENED Resolution|FIXED |---
[Bug c++/120289] New: internal compiler error: tree check: accessed elt 2 of 'tree_vec' with 1 elts in tsubst, at cp/pt.cc:16650 since 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120289
Bug ID: 120289
Summary: internal compiler error: tree check: accessed elt 2 of
'tree_vec' with 1 elts in tsubst, at cp/pt.cc:16650
since 6.1
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
Code thats produce ICE:
```
#include
template >
class std::allocator{}
```
Stack dump
```
/opt/compiler-explorer/gcc-trunk-20250515/include/c++/16.0.0/bits/allocator.h:183:9:
internal compiler error: tree check: accessed elt 2 of 'tree_vec' with 1 elts
in tsubst, at cp/pt.cc:16650
183 | allocator(const allocator<_Tp1>&) _GLIBCXX_NOTHROW { }
| ^
0x2943505 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2961276 internal_error(char const*, ...)
???:0
0x9e3b59 tree_vec_elt_check_failed(int, int, char const*, int, char const*)
???:0
0xb57966 tree_vec_elt_check(tree_node*, int, char const*, int, char const*)
???:0
0xd35054 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd48ee9 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0xd33f01 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd5156d instantiate_template(tree_node*, tree_node*, int)
???:0
0xd510b3 instantiate_template(tree_node*, tree_node*, int)
???:0
0xd5cc8a fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0xaf94bb build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0xc36acf implicitly_declare_fn(special_function_kind, tree_node*, bool,
tree_node*, tree_node*)
???:0
0xc37a75 lazily_declare_fn(special_function_kind, tree_node*)
???:0
0xc7d611 get_class_binding(tree_node*, tree_node*, bool)
???:0
0xd6ec98 lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
???:0
0xd6f244 lookup_fnfields(tree_node*, tree_node*, int, int)
???:0
0xafab7d build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
???:0
0xc07b5a build_aggr_init(tree_node*, tree_node*, int, int)
???:0
0xc0cec4 emit_mem_initializers(tree_node*)
???:0
0xd2772d instantiate_decl(tree_node*, bool, bool)
???:0
```
To quickly reproduce:
In no asserted versions, bailing out is shown instead of ICE
https://godbolt.org/z/j5hPbWjEn
[Bug c++/86769] [12/13/14 Regression] g++ destroys condition variable in for statement too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86769
--- Comment #27 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:24cd4753e470ec122d232c9da825274bce0bae15
commit r14-11787-g24cd4753e470ec122d232c9da825274bce0bae15
Author: Jakub Jelinek
Date: Fri Feb 7 17:07:23 2025 +0100
c++: Fix up handling of for/while loops with declarations in condition
[PR86769]
As the following testcase show (note, just for-{3,4,6,7,8}.C,
constexpr-86769.C
and stmtexpr27.C FAIL without the patch, the rest is just that I couldn't
find coverage for some details and so added tests we don't regress or
for5.C
is from Marek's attempt in the PR), we weren't correctly handling for/while
loops with declarations as conditions.
The C++ FE has the simplify_loop_decl_cond function which transforms
such loops as mentioned in the comment:
while (A x = 42) { }
for (; A x = 42;) { }
becomes
while (true) { A x = 42; if (!x) break; }
for (;;) { A x = 42; if (!x) break; }
For for loops this is not enough, as the x declaration should be
still in scope when expr (if any) is executed, and injecting the
expr expression into the body in the FE needs to have the continue
label in between, something normally added by the c-family
genericization. One of my thoughts was to just add there an artificial
label plus the expr expression in the FE and tell c-family about that
label, so that it doesn't create it but uses what has been emitted.
Unfortunately break/continue are resolved to labels only at c-family
genericization time and by moving the condition (and its preparation
statements such as the DECL_EXPR) into the body (and perhaps by also
moving there the (increment) expr as well) we resolve incorrectly any
break/continue statement appearing in cond (or newly perhaps also expr)
expression(s). While in standard C++ one can't have something like that
there, with statement expressions they are possible there, and we actually
have testsuite coverage that when they appear outside of the body of the
loop they bind to an outer loop rather than the inner one. When the FE
moves everything into the body, c-family can't distinguish any more between
the user body vs. the condition/preparation statements vs. expr expression.
So, the following patch instead keeps them separate and does the merging
only at the c-family loop genericization time. For that the patch
introduces two new operands of FOR_STMT and WHILE_STMT, *_COND_PREP
which is forced to be a BIND_EXPR which contains the preparation statements
like DECL_EXPR, and the initialization of that variable, so basically what
{FOR,WHILE}_BODY has when we encounter the function dealing with this,
except one optional CLEANUP_STMT at the end which holds cleanups for the
variable if it needs to be destructed. This CLEANUP_STMT is removed and
the actual cleanup saved into another new operand, *_COND_CLEANUP.
The c-family loop genericization handles such loops roughly the way
https://eel.is/c++draft/stmt.for and https://eel.is/c++draft/stmt.while
specifies, so the body is (if *_COND_CLEANUP is non-NULL)
{ A x = 42; try { if (!x) break; body; cont_label: expr; } finally {
cleanup; } }
and otherwise
{ A x = 42; if (!x) break; body; cont_label: expr; }
i.e. the *_COND, *_BODY, optional continue label, FOR_EXPR are appended
into the body of the *_COND_PREP BIND_EXPR.
And when doing constexpr evaluation of such FOR/WHILE loops, we treat
it similarly, first evaluate *_COND_PREP except the
for (tree decl = BIND_EXPR_VARS (t); decl; decl = DECL_CHAIN (decl))
destroy_value_checked (ctx, decl, non_constant_p);
part of BIND_EXPR handling for it, then evaluate *_COND (and decide based
on whether it was false or true like before), then *_BODY, then FOR_EXPR,
then *_COND_CLEANUP (similarly to the way how CLEANUP_STMT handling handles
that) and finally do those destroy_value_checked.
Note, the constexpr-86769.C testcase FAILs with both clang++ and MSVC
(note,
the rest of tests PASS with clang++) but I believe it must be just a bug
in those compilers, new int is done in all the constructors and delete is
done in the destructor, so when clang++ reports one of the new int weren't
deallocated during constexpr evaluation I don't see how that would be
possible. When the same test has all the constexpr stuff, all the new int
are properly deleted at runtime when compiled by both compilers and
valgrind
is happy about it, no leaks.
2025-02-07 Jakub Jelinek
Jason Merrill
PR c++/86769
gcc/c-family/
* c-common.def (FOR_STMT): Add 2 operands and document them.
(WHILE_STMT): Likewise.
*
[Bug rtl-optimization/118623] [12/13/14 regression] Miscompile with -O2/3 and -O0/1 since r12-7751-g919fbffef07555
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118623
--- Comment #20 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:aa4cd614456de65ee3417acb83c6cff0640144e9
commit r14-11789-gaa4cd614456de65ee3417acb83c6cff0640144e9
Author: Jakub Jelinek
Date: Mon Feb 10 10:40:22 2025 +0100
i386: Change RTL representation of bt[lq] [PR118623]
The following testcase is miscompiled because of RTL represententation
of bt{l,q} insn followed by e.g. j{c,nc} being misleading to what it
actually does.
Let's look e.g. at
(define_insn_and_split "*jcc_bt"
[(set (pc)
(if_then_else (match_operator 0 "bt_comparison_operator"
[(zero_extract:SWI48
(match_operand:SWI48 1 "nonimmediate_operand")
(const_int 1)
(match_operand:QI 2 "nonmemory_operand"))
(const_int 0)])
(label_ref (match_operand 3))
(pc)))
(clobber (reg:CC FLAGS_REG))]
"(TARGET_USE_BT || optimize_function_for_size_p (cfun))
&& (CONST_INT_P (operands[2])
? (INTVAL (operands[2]) < GET_MODE_BITSIZE (mode)
&& INTVAL (operands[2])
>= (optimize_function_for_size_p (cfun) ? 8 : 32))
: !memory_operand (operands[1], mode))
&& ix86_pre_reload_split ()"
"#"
"&& 1"
[(set (reg:CCC FLAGS_REG)
(compare:CCC
(zero_extract:SWI48
(match_dup 1)
(const_int 1)
(match_dup 2))
(const_int 0)))
(set (pc)
(if_then_else (match_op_dup 0 [(reg:CCC FLAGS_REG) (const_int 0)])
(label_ref (match_dup 3))
(pc)))]
{
operands[0] = shallow_copy_rtx (operands[0]);
PUT_CODE (operands[0], reverse_condition (GET_CODE (operands[0])));
})
The define_insn part in RTL describes exactly what it does,
jumps to op3 if bit op2 in op1 is set (for op0 NE) or not set (for op0 EQ).
The problem is with what it splits into.
put_condition_code %C1 for CCCmode comparisons emits c for EQ and LTU,
nc for NE and GEU and ICEs otherwise.
CCCmode is used mainly for carry out of add/adc, borrow out of sub/sbb,
in those cases e.g. for add we have
(set (reg:CCC flags) (compare:CCC (plus:M x y) x))
and use (ltu (reg:CCC flags) (const_int 0)) for carry set and
(geu (reg:CCC flags) (const_int 0)) for carry not set. These cases
model in RTL what is actually happening, compare in infinite precision
x from the result of finite precision addition in M mode and if it is
less than unsigned (i.e. overflow happened), carry is set.
Another use of CCCmode is in UNSPEC_* patterns, those are used with
(eq (reg:CCC flags) (const_int 0)) for carry set and ne for unset,
given the UNSPEC no big deal, the middle-end doesn't know what means
set or unset.
But for the bt{l,q}; j{c,nc} case the above splits it into
(set (reg:CCC flags) (compare:CCC (zero_extract) (const_int 0)))
for bt and
(set (pc) (if_then_else (eq (reg:CCC flags) (const_int 0)) (label_ref)
(pc)))
for the bit set case (so that the jump expands to jc) and ne for
the bit not set case (so that the jump expands to jnc).
Similarly for the different splitters for cmov and set{c,nc} etc.
The problem is that when the middle-end reads this RTL, it feels
the exact opposite to it. If zero_extract is 1, flags is set
to comparison of 1 and 0 and that would mean using ne ne in the
if_then_else, and vice versa.
So, in order to better describe in RTL what is actually happening,
one possibility would be to swap the behavior of put_condition_code
and use NE + LTU -> c and EQ + GEU -> nc rather than the current
EQ + LTU -> c and NE + GEU -> nc; and adjust everything. The
following patch uses a more limited approach, instead of representing
bt{l,q}; j{c,nc} case as written above it uses
(set (reg:CCC flags) (compare:CCC (const_int 0) (zero_extract)))
and
(set (pc) (if_then_else (ltu (reg:CCC flags) (const_int 0)) (label_ref)
(pc)))
which uses the existing put_condition_code but describes what the
insns actually do in RTL clearly. If zero_extract is 1,
then flags are LTU, 0U < 1U, if zero_extract is 0, then flags are GEU,
0U >= 0U. The patch adjusts the *bt define_insn and all the
splitters to it and its comparisons/conditional moves/setXX.
2025-02-10 Jakub Jelinek
PR target/118623
* config/i386/i386.md (*bt): Represent bt as
compare:CCC of const0_rtx and zero_extract rather than
zero_extract and const0_rtx.
(*bt_mask): Likewise.
(*jcc_bt): Likewise. Use LTU and GEU as flags test
[Bug rtl-optimization/118623] [12/13 regression] Miscompile with -O2/3 and -O0/1 since r12-7751-g919fbffef07555
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118623 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[12/13/14 regression] |[12/13 regression] |Miscompile with -O2/3 and |Miscompile with -O2/3 and |-O0/1 since |-O0/1 since |r12-7751-g919fbffef07555|r12-7751-g919fbffef07555 Status|NEW |ASSIGNED --- Comment #21 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug c++/86769] [12/13 Regression] g++ destroys condition variable in for statement too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86769 Jakub Jelinek changed: What|Removed |Added Summary|[12/13/14 Regression] g++ |[12/13 Regression] g++ |destroys condition variable |destroys condition variable |in for statement too early |in for statement too early --- Comment #28 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug c++/118822] [15 regression] ICE when building mariadb-10.6.21 since r15-7426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118822
--- Comment #11 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:db73411a72cf2052dddcf9fa0523588599a73537
commit r14-11788-gdb73411a72cf2052dddcf9fa0523588599a73537
Author: Jakub Jelinek
Date: Thu Feb 13 10:21:29 2025 +0100
c++: Fix up regressions caused by for/while loops with declarations
[PR118822]
The recent PR86769 r15-7426 changes regressed the following two testcases,
the first one is more important as it is derived from real-world code.
The first problem is that the chosen
prep = do_pushlevel (sk_block);
// emit something
body = push_stmt_list ();
// emit further stuff
body = pop_stmt_list (body);
prep = do_poplevel (prep);
way of constructing the {FOR,WHILE}_COND_PREP and {FOR,WHILE}_BODY
isn't reliable. If during parsing a label is seen in the body and then
some decl with destructors, sk_cleanup transparent scope is added, but
the correspondiong result from push_stmt_list is saved in
*current_binding_level and pop_stmt_list then pops even that statement list
but only do_poplevel actually attempts to pop the sk_cleanup scope and so
we
ICE.
The reason for not doing do_pushlevel (sk_block); do_pushlevel (sk_block);
is that variables should be in the same scope (otherwise various e.g.
redeclaration*.C tests FAIL) and doing do_pushlevel (sk_block);
do_pushlevel
(sk_cleanup); wouldn't work either as do_poplevel would silently unwind
even
the cleanup one.
So, the following patch changes the earlier approach. Nothing is removed
from the {FOR,WHILE}_COND_PREP subtrees while doing adjust_loop_decl_cond,
push_stmt_list isn't called either; all it does is remember as an integer
the number of cleanups (CLEANUP_STMT at the end of the STATEMENT_LISTs)
from querying stmt_list_stack and finding the initial *body_p in there
(that integer is stored into {FOR,WHILE}_COND_CLEANUP), and temporarily
{FOR,WHILE}_BODY is set to the last statement (if any) in the innermost
STATEMENT_LIST at the adjust_loop_decl_cond time; then at
finish_{for,while}_stmt a new finish_loop_cond_prep routine takes care of
do_poplevel for the scope (which is in {FOR,WHILE}_COND_PREP) and finds
given {FOR,WHILE}_COND_CLEANUP number and {FOR,WHILE}_BODY tree the right
spot where body statements start and moves that into {FOR,WHILE}_BODY.
Finally genericize_c_loop then inserts the cond, body, continue label, expr
into the right subtree of {FOR,WHILE}_COND_PREP.
The constexpr evaluation unfortunately had to be changed as well, because
we don't want to evaluate everything in BIND_EXPR_BODY (*_COND_PREP ())
right away, we want to evaluate it with the exception of the CLEANUP_STMT
cleanups at the end (given {FOR,WHILE}_COND_CLEANUP levels), and defer
the evaluation of the cleanups until after cond, body, expr are evaluated.
2025-02-13 Jakub Jelinek
PR c++/118822
gcc/
* tree-iterator.h (tsi_split_stmt_list): Declare.
* tree-iterator.cc (tsi_split_stmt_list): New function.
gcc/c-family/
* c-common.h (WHILE_COND_CLEANUP): Change description in comment.
(FOR_COND_CLEANUP): Likewise.
* c-gimplify.cc (genericize_c_loop): Adjust for COND_CLEANUP
being CLEANUP_STMT/TRY_FINALLY_EXPR trailing nesting depth
instead of actual cleanup.
gcc/cp/
* semantics.cc (adjust_loop_decl_cond): Allow multiple trailing
CLEANUP_STMT levels in *BODY_P. Set *CLEANUP_P to the number
of levels rather than one particular cleanup, keep the cleanups
in *PREP_P. Set *BODY_P to the last stmt in the cur_stmt_list
or NULL if *CLEANUP_P and the innermost cur_stmt_list is empty.
(finish_loop_cond_prep): New function.
(finish_while_stmt, finish_for_stmt): Use it. Don't call
set_one_cleanup_loc.
* constexpr.cc (cxx_eval_loop_expr): Adjust handling of
{FOR,WHILE}_COND_{PREP,CLEANUP}.
gcc/testsuite/
* g++.dg/expr/for9.C: New test.
(cherry picked from commit 26baa2c09b39abf037afad349a318dc5734eae25)
[Bug c++/120290] New: internal compiler error: in expand_asm_stmt, at cfgexpand.cc:3720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120290
Bug ID: 120290
Summary: internal compiler error: in expand_asm_stmt, at
cfgexpand.cc:3720
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
ICE in expand_asm_stmt at cfgexpand.cc:3720 with inline assembly using mov
%eax, 12(%edi):
```
#include
int main(){
int i = 7;
int *k = &i;
asm volatile("mov %eax, 12(%edi)\n"
: " =r" (k)
: "0" (k)
: "eax", "edi");
}
```
Stack dump:
```
during RTL pass: expand
:5:5: internal compiler error: in expand_asm_stmt, at cfgexpand.cc:3720
0x2943505 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2961276 internal_error(char const*, ...)
???:0
0xad8a2c fancy_abort(char const*, int, char const*)
???:0
```
It happens since first clang, but hiiden by bailing out
https://godbolt.org/z/8reMYva4a
[Bug c++/120291] New: internal compiler error: in tsubst_pack_expansion, at cp/pt.cc:13941 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120291
Bug ID: 120291
Summary: internal compiler error: in tsubst_pack_expansion, at
cp/pt.cc:13941 with -std=c++20
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
It ICEs in invalid this invalid code:
```
#include
template decltype(auto) f() {
return [](auto... args) mutable requires requires {
A a;
}(...);
};
}
int main() {
f<0>()(A<0>{});
}
```
Stack dump
```
:3:9: internal compiler error: in tsubst_pack_expansion, at
cp/pt.cc:13941
3 | return [](auto... args) mutable requires requires {
| ^~~~
4 |A**, int)
???:0
0xd7dc7c finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0xcfcda3 c_parse_file()
???:0
0xe5f7c9 c_common_parse_file()
???:0
```
To quickly reproduce with -std=c++20:
https://godbolt.org/z/73r594779
[Bug c++/120288] New: spurious null pointer dereference in std::__detail::_Hashtable_base::_M_key_equals since gcc-15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120288
Bug ID: 120288
Summary: spurious null pointer dereference in
std::__detail::_Hashtable_base::_M_key_equals since
gcc-15
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: adl at gnu dot org
Target Milestone: ---
Created attachment 61428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61428&action=edit
preprocessed sources
The following code produces spurious "potential null pointer dereference" with
GCC 15.1 and Debian's gcc-snapshot (20250502).
Those false positives where not produced with GCC 14.2 and earlier.
I found it quite hard to reduce the problem, because the diagnostics were only
pointing to the C++ headers, without any indication of what part of my code
called that method.
https://godbolt.org/z/s7W46dqnj
% cat foo.cc
#include
class key
{
};
bool less_than(const key* left, const key* right) noexcept;
struct hash
{
size_t
operator()(const key*) const noexcept
{
return 0;
}
};
struct equal
{
bool
operator()(const key* left, const key* right) const noexcept
{
return less_than(left, right);
}
};
class foo
{
public:
foo();
private:
std::unordered_map map;
};
foo::foo()
{
key b;
map.find(&b);
}
% g++ -O -Wnull-dereference -Werror -c foo.cc
In file included from /usr/lib/gcc-snapshot/include/c++/16/bits/hashtable.h:37,
from
/usr/lib/gcc-snapshot/include/c++/16/bits/unordered_map.h:33,
from /usr/lib/gcc-snapshot/include/c++/16/unordered_map:43,
from foo.cc:1:
In member function 'bool std::__detail::_Hashtable_base<_Key, _Value,
_ExtractKey, _Equal, _Hash, _RangeHash, _Unused, _Traits>::_M_key_equals(const
_Key&, const std::__detail::_Hash_node_value<_Value, typename
_Traits::__hash_cached::value>&) const [with _Key = const key*; _Value =
std::pair; _ExtractKey = std::__detail::_Select1st;
_Equal = equal; _Hash = hash; _RangeHash = std::__detail::_Mod_range_hashing;
_Unused = std::__detail::_Default_ranged_hash; _Traits =
std::__detail::_Hashtable_traits]',
inlined from 'std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal,
_Hash, _RangeHash, _Unused, _RehashPolicy, _Traits>::__location_type
std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal, _Hash, _RangeHash,
_Unused, _RehashPolicy, _Traits>::_M_locate(const key_type&) const [with _Key =
const key*; _Value = std::pair; _Alloc =
std::allocator >; _ExtractKey =
std::__detail::_Select1st; _Equal = equal; _Hash = hash; _RangeHash =
std::__detail::_Mod_range_hashing; _Unused =
std::__detail::_Default_ranged_hash; _RehashPolicy =
std::__detail::_Prime_rehash_policy; _Traits =
std::__detail::_Hashtable_traits]' at
/usr/lib/gcc-snapshot/include/c++/16/bits/hashtable.h:2272:31,
inlined from 'std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal,
_Hash, _RangeHash, _Unused, _RehashPolicy, _Traits>::iterator
std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal, _Hash, _RangeHash,
_Unused, _RehashPolicy, _Traits>::find(const key_type&) [with _Key = const
key*; _Value = std::pair; _Alloc =
std::allocator >; _ExtractKey =
std::__detail::_Select1st; _Equal = equal; _Hash = hash; _RangeHash =
std::__detail::_Mod_range_hashing; _Unused =
std::__detail::_Default_ranged_hash; _RehashPolicy =
std::__detail::_Prime_rehash_policy; _Traits =
std::__detail::_Hashtable_traits]' at
/usr/lib/gcc-snapshot/include/c++/16/bits/hashtable.h:1918:32:
/usr/lib/gcc-snapshot/include/c++/16/bits/hashtable_policy.h:1409:23: error:
potential null pointer dereference [-Werror=null-dereference]
1409 | return _M_eq()(__k, _ExtractKey{}(__n._M_v()));
|~~~^~~~
cc1plus: all warnings being treated as errors
[Bug target/120292] New: amdgcn: Infinite recursion in vec_cmpudi_exec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120292
Bug ID: 120292
Summary: amdgcn: Infinite recursion in vec_cmpudi_exec
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: amdgcn*-*-*
The following pattern is infinitely recursive. It looks like it should be
calling "vec_cmp..." rather than "vec_cmpu...":
(define_expand "vec_cmpudi_exec"
[(match_operand:DI 0 "register_operand")
(match_operator 1 "gcn_compare_operator"
[(match_operand:V_INT_noQI 2 "gcn_alu_operand")
(match_operand:V_INT_noQI 3 "gcn_vop3_operand")])
(match_operand:DI 4 "gcn_exec_reg_operand")]
""
{
/* Unsigned comparisons use the same patterns as signed comparisons,
except that they use unsigned operators (e.g. LTU vs LT).
The '%E1' directive then does the Right Thing. */
emit_insn (gen_vec_cmpudi_exec (operands[0], operands[1],
operands[2], operands[3],
operands[4]));
DONE;
})
This causes a build of amdgcn-amdhsa to fail with --enable-werror:
.../gcc/config/gcn/gcn-valu.md: In function ‘rtx_def*
gen_vec_cmpuv32sidi_exec(rtx, rtx, rtx, rtx, rtx)’:
.../gcc/config/gcn/gcn-valu.md:3815:1: error: infinite recursion detected
[-Werror=infinite-recursion]
3815 | emit_insn (gen_2_exec (sitmp1, operands[2],
| ^
.../gcc/config/gcn/gcn-valu.md:3798:15: note: recursive call
3798 | emit_insn (gen_vec_cmpudi_exec (operands[0], operands[1],
| ~~^
3799 | operands[2], operands[3],
| ~
3800 | operands[4]));
| ~
cc1plus: all warnings being treated as errors
[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 #9 from Andreas Schwab --- Note that a formal proc argument named "args" is a special case in tcl as it collects all (remaining) arguments as a list. Either the argument needs to be named differently (like "locale") or the proc needs to use [lindex $args 0] to access the first (and only) argument.
[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 #10 from Jonathan Wakely ---
Ugh, I forgot that we sometimes use dg-require-namedlocale with an empty
string. I only checked that the change worked for some tests using non-empty
names.
I don't know why the old code worked when doing:
set result [${tool}_load "./$exe" "$args" ""]
But the new code expands $args to {} when doing:
puts $f " const char *namedloc = transform_locale(\"$args\");"
Some tcl weirdness, I guess.
This works, but is pretty ugly:
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -1048,7 +1048,11 @@ proc check_v3_target_namedlocale { args } {
puts $f "}"
puts $f "int main ()"
puts $f "{"
- puts $f " const char *namedloc = transform_locale(\"$args\");"
+ if { [lindex $args 0] == "" } {
+ puts $f " const char *namedloc = new char\[1\]();"
+ } else {
+ puts $f " const char *namedloc = transform_locale(\"$args\");"
+ }
puts $f " try"
puts $f " {"
puts $f "locale((const char*)namedloc);"
[Bug c++/120272] [13/14/15/16 Regression] ICE in get_local_decls, at cp/name-lookup.c:4594 since 13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120272 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #2 from mcccs at gmx dot com --- r14-5514-g70060dadfbf0d0
[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 #11 from Jonathan Wakely ---
(In reply to Andreas Schwab from comment #9)
> Note that a formal proc argument named "args" is a special case in tcl as it
> collects all (remaining) arguments as a list. Either the argument needs to
> be named differently (like "locale") or the proc needs to use [lindex $args
> 0] to access the first (and only) argument.
Ah, I didn't know args was special, thanks.
But why did [${tool}_load "./$exe" "$args" ""] do the right thing in the
original code?
[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 #12 from Jonathan Wakely --- Maybe "$args" is special too, and not the same as "blah $args blah"?
[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 #13 from Jonathan Wakely ---
No, it seems to be a property of dejagnu's remote_load and standard_load procs
(which ${tool}_load uses) that interprets the argument as a list and then uses
"" if it's an empty list.
[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 #14 from Jonathan Wakely --- I think I'll just change the formal argument name to locale instead of args. We only want to accept a single argument, not a list, and now $locale works because it's not a list. I should audit the other procs in libstdc++.exp to see if the same change makes sense.
[Bug tree-optimization/120279] Missed DCE for __builtin_{clzg,ctzg} when bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120279 --- Comment #2 from Kael Franco --- (In reply to Richard Biener from comment #1) > I'm not sure what you are after? That in f1() the earlier of both shifts > can be removed? Correct.
[Bug middle-end/120278] [12/13/14/15 Regression] Switch expansion generates extra compares with -fno-jump-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278 --- Comment #5 from Ken Young --- So -O0 should be expected to generate incorrect decision trees for switch/case statements now in order to reduce some amount of compile time? Even though it used to correctly generate the decision tree?
[Bug c++/120285] ice in digest_init_r, at cp/typeck2.cc:1397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120285 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #1 from mcccs at gmx dot com --- r15-3933-g96e0370f4daef2
[Bug middle-end/120278] [12/13/14/15 Regression] Switch expansion generates extra compares with -fno-jump-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- What do you mean by incorrect? Do you have any proof of a wrong-code, where the code emitted for -O0 misbehaves, as opposed to just inefficient code? The latter is very much expected to be there at -O0, the main intent of -O0 is fast compile time and reasonable debuggability.
[Bug c++/99599] [12/13 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599 --- Comment #31 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2ee1fce9fc35de21b28823ccae433c90a0ce270b commit r16-651-g2ee1fce9fc35de21b28823ccae433c90a0ce270b Author: Jason Merrill Date: Wed May 14 10:23:32 2025 -0400 c++: one more PR99599 tweak Patrick pointed out that if the parm/arg types aren't complete yet at this point, it would affect the type_has_converting_constructor and TYPE_HAS_CONVERSION tests. I don't have a testcase, but it makes sense for safety. PR c++/99599 gcc/cp/ChangeLog: * pt.cc (conversion_may_instantiate_p): Make sure classes are complete.
[Bug cobol/119825] SIGSEGV when using qualified names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119825 James K. Lowden changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from James K. Lowden --- Fixed by d897d5d25add21e6f02806e19cb689d63286d6b8. Thank you for reporting the error.
[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 --- Comment #7 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:0c430503f2849ebb20105695b8ad40d43d797c7b commit r16-654-g0c430503f2849ebb20105695b8ad40d43d797c7b Author: Patrick Palka Date: Thu May 15 11:07:53 2025 -0400 c++: unifying specializations of non-primary tmpls [PR120161] Here unification of P=Wrap::type, A=Wrap::type wrongly succeeds ever since r14-4112 which made the RECORD_TYPE case of unify no longer recurse into template arguments for non-primary templates (since they're a non-deduced context) and so the int/long mismatch that makes the two types distinct goes unnoticed. In the case of (comparing specializations of) a non-primary template, unify should still go on to compare the types directly before returning success. PR c++/120161 gcc/cp/ChangeLog: * pt.cc (unify) : When comparing specializations of a non-primary template, still perform a type comparison. gcc/testsuite/ChangeLog: * g++.dg/template/unify13.C: New test. Reviewed-by: Jason Merrill
[Bug libstdc++/110739] std::format for chrono types compiles very slowly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110739 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |16.0
[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 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jeffrey A. Law --- Should be fixed on the trunk.
[Bug middle-end/120278] [12/13/14/15 Regression] Switch expansion generates extra compares with -fno-jump-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278 --- Comment #7 from Ken Young --- I guess what I mean by "incorrect" is a branch tree where some of the branch nodes will never evaluate for both true and false conditions. I now see that the switch/case "cleanup" has been moved to an optimization pass as it's acceptable to increase compile time when optimizing. It's just unfortunate for critical device applications where we can't just accept everything done in -O1 or -Og generated code and essentially have to work with -O0.
[Bug libstdc++/120293] New: std::format("{}", std::chrono::sys_days()) should not include time-of-day
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120293
Bug ID: 120293
Summary: std::format("{}", std::chrono::sys_days()) should not
include time-of-day
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
std::format("{}", std::chrono::sys_days()) should be "1970-01-01" but we
currently produce "1970-01-01 00:00:00"
This fixes it:
--- a/libstdc++-v3/include/bits/chrono_io.h
+++ b/libstdc++-v3/include/bits/chrono_io.h
@@ -766,6 +766,9 @@ namespace __format
// sys_time with period greater or equal to days:
if constexpr (is_convertible_v<_Tp, chrono::sys_days>)
__os << _S_date(__t);
+ // Or a local_time with period greater or equal to days:
+ else if constexpr (is_convertible_v<_Tp, chrono::local_days>)
+ __os << _S_date(__t);
else // Or it's formatted as "{:L%F %T}":
{
auto __days = chrono::floor(__t);
[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 #3 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:87d0daab1ec9d5c901295e8045cbd67f80b2fa23 commit r16-655-g87d0daab1ec9d5c901295e8045cbd67f80b2fa23 Author: Jeff Law Date: Thu May 15 09:03:13 2025 -0600 [RISC-V][PR target/120223] Don't use bset/binv for XTHEADBS Thead has the XTHEADBB extension which has a lot of overlap with Zbb. I made the incorrect assumption that XTHEADBS would largely be like Zbs when generalizing Shreya's work. As a result we can't use the operation synthesis code for IOR/XOR because we don't have binv/bset like capabilities. I should have double checked on XTHEADBS, my bad. Anyway, the fix is trivial. Don't allow bset/binv based on XTHEADBS. Already spun in my tester. Spinning in the pre-commit CI system now. PR target/120223 gcc/ * config/riscv/riscv.cc (synthesize_ior_xor): XTHEADBS does not have single bit manipulations. gcc/testsuite/ * gcc.target/riscv/pr120223.c: New test.
[Bug tree-optimization/120294] New: Missed DCE with xor when emulating __builtin_ctzg() with __builtin_ctz()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120294 Bug ID: 120294 Summary: Missed DCE with xor when emulating __builtin_ctzg() with __builtin_ctz() Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: kaelfandrew at gmail dot com Target Milestone: --- Created attachment 61429 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61429&action=edit C code GCC does not remove xor edx, edx in f0_slow() but it does in f0_fast() with flags -O3 -march=icelake-client. LLVM does remove the extra xor. gcc -v == Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/16/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/16 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/16/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/16/include/g++-v16 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/16/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=yes,extra --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 16.0. p, commit 05d9c70131be267bfe5b36e663acda8729da6456' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-offload-defaulted --enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp --disable-libada --enable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --with-isl --disable-isl-version-check --enable-default-pie --enable-host-pie --enable-host-bind-now --enable-default-ssp --disable-fixincludes --with-gxx-libcxx-include-dir=/usr/include/c++/v1 --with-build-config='bootstrap-lto bootstrap-cet' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 16.0.0 20250423 (experimental) e9a81addd5b7d018e173fa8d59aafc2f84e41d8b (Gentoo 16.0. p, commit 05d9c70131be267bfe5b36e663acda8729da6456)
[Bug libstdc++/120293] std::format("{}", std::chrono::local_days()) should not include time-of-day
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120293
Jonathan Wakely changed:
What|Removed |Added
Summary|std::format("{}", |std::format("{}",
|std::chrono::sys_days())|std::chrono::local_days())
|should not include |should not include
|time-of-day |time-of-day
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2025-05-15
--- Comment #1 from Jonathan Wakely ---
Oops, the bug is with local_days not sys_days. We get sys_days right. I've
fixed the summary but can't fix comment 0.
The full reproducer is:
#include
#include
#include
int main()
{
assert( std::format("{}", std::chrono::local_days()) == "1970-01-01" );
}
[Bug libstdc++/120190] Definition of the primary template of std::format_kind seems IFNDR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120190 --- Comment #2 from Jonathan Wakely --- Fixed on trunk, backport needed for 15.2
[Bug libstdc++/120190] Definition of the primary template of std::format_kind seems IFNDR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120190 --- Comment #1 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c65725eccbabf3b9b5965f27fff2d3b9f6c75930 commit r16-658-gc65725eccbabf3b9b5965f27fff2d3b9f6c75930 Author: Jonathan Wakely Date: Thu May 15 11:01:05 2025 +0100 libstdc++: Fix std::format_kind primary template for Clang [PR120190] Although Clang trunk has been adjusted to handle our std::format_kind definition (because they need to be able to compile the GCC 15.1.0 release), it's probably better to not rely on something that they might start diagnosing again in future. Define the primary template in terms of an immediately invoked function expression, so that we can put a static_assert(false) in the body. libstdc++-v3/ChangeLog: PR libstdc++/120190 * include/std/format (format_kind): Adjust primary template to not depend on itself. * testsuite/std/format/ranges/format_kind_neg.cc: Adjust expected errors. Check more invalid specializations. Reviewed-by: Tomasz KamiÅski Reviewed-by: Daniel Krügler
[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|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- .
[Bug libstdc++/120235] std::fabs(const std::complex&) should not be defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120235 --- Comment #3 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6dbcbd96e90159e87a339b98192b7e6e5534b0d7 commit r16-656-g6dbcbd96e90159e87a339b98192b7e6e5534b0d7 Author: Jonathan Wakely Date: Mon May 12 11:34:01 2025 +0100 libstdc++: Deprecate non-standard std::fabs(const complex&) [PR120235] There was an overload of fabs for std::complex in TR1 and in some C++0x drafts, but it was removed from the working draft by LWG 595. Since we've been providing it for decades we should deprecate it before removing it. libstdc++-v3/ChangeLog: PR libstdc++/120235 * doc/html/*: Regenerate. * doc/xml/manual/evolution.xml: Document deprecation. * include/std/complex: Replace references to TR1 subclauses with corresponding C++11 subclauses. (fabs): Add deprecated attribute. * testsuite/26_numerics/complex/fabs_neg.cc: New test. Reviewed-by: Tomasz KamiÅski
[Bug c++/120273] [15/16 regression] ICE when building corral
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120273 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #6 from mcccs at gmx dot com --- r15-3148-g6303cd7e41546e
[Bug target/120294] Missed DCE with xor when emulating __builtin_ctzg() with __builtin_ctz() and bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120294 --- Comment #1 from mcccs at gmx dot com --- pr95861 was also closed - there was a bug in intel hardware that caused dependency detection false positive, so it would be slow without the xor
[Bug tree-optimization/120295] New: Wrong code on -O3 for trunk version (live code is wrongly eliminated)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120295
Bug ID: 120295
Summary: Wrong code on -O3 for trunk version (live code is
wrongly eliminated)
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi,
We found an interesting wrong-code issue with our new testing tool. It seems
gcc-trunk with -O3 eliminates a live code block for some reasons. Please look
at the details below.
$cat small.c
#include
#include
struct {
signed a;
} b;
#define t(w, x)
\
({
\
int64_t y = w;
\
y;
\
})
#define z(aa, ac)
\
({
\
int16_t ad = aa;
\
ad<0 || ad> e;
\
})
int a, f, j, l;
int8_t c, k, g, e;
int16_t d[2] = {0};
int32_t *i = &j;
void marker_37() {
a++;
printf("%d\n", a);
}
uint64_t m(uint32_t, int8_t, uint32_t, int16_t);
int32_t n(uint8_t, int64_t, int32_t);
int32_t o(uint32_t, int64_t, uint32_t);
uint16_t p(void) {
int32_t *r = &l;
*r |= t((m(c, c, 0, c), b.a), );
return 0;
}
uint64_t m(uint32_t q, int8_t v, uint32_t s, int16_t u) {
uint16_t ab = 5;
if (n(ab, d[1], q))
for (; g; g++)
;
return c;
}
int32_t n(uint8_t e, int64_t ae, int32_t af) {
uint32_t ag = 4;
int32_t *ah = &f;
*ah = z(o(f, af, ag), 4);
return *i;
}
int32_t o(uint32_t ai, int64_t aj, uint32_t ak) {
for (; e; e--) {
int32_t *al = &f;
for (; k; k++)
*al = 0;
}
if (18446744073709551606UL != (uint64_t) aj)
;
else
marker_37();
return ak;
}
int main() {
c = 0xf6;
p();
return 0;
}
$gcc-trunk -w -std=c99 -O0 small.c -o t0 ; ./t0
1
$gcc-trunk -w -std=c99 -O1 small.c -o t1 ; ./t1
1
$gcc-trunk -w -std=c99 -O3 small.c -o t2 ; ./t2
Segmentation fault (core dumped)
$gcc-11.1.0 -w -std=c99 -O3 small.c -o t4 ; ./t4
1
$clang-20 -w -std=c99 -O3 small.c -o t5 ; ./t5
1
Interestingly, the function call `marker_37` is eliminated in the binary t2.
$objdump -S t2 | grep marker_37
00401150 :
$objdump -S t1 | grep marker_37
00401128 :
4011c2: e8 61 ff ff ff callq 401128
$gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/research/compilers/gcc/build-master/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/home/research/compilers/gcc/build-master --enable-bootstrap
--enable-checking=release --enable-languages=c,c++ --enable-multilib
--program-suffix=-trunk : (reconfigured) ../configure
--prefix=/home/research/compilers/gcc/build-master --enable-bootstrap
--enable-checking=release --enable-multilib --program-suffix=-trunk
--enable-languages=c,c++,lto --no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250515 (experimental) (GCC)
Reproduced in Godblot: https://godbolt.org/z/1x1Kvb38z. From there, it seems
there is something broken after GCC-14.1.
Could you please help check it?
Thanks,
Haoxin
[Bug cobol/119809] FE internal_error internal compiler error: in digits_from_float128, at cobol/genapi.cc:15293 (bit data items)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119809 --- Comment #4 from Simon Sobisch --- Looking forward to have a compiler targetting ISO COBOL to support that one day :-) Note: in C this would be a struct with int : 1, included, I think.
[Bug target/120008] RFE: x86: explicit compiler support for SMAP stac/clac (possibly via __attribute__((user))) or similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120008 --- Comment #2 from H. Peter Anvin --- Could you please clarify why you think this is not a good idea?
[Bug libstdc++/120299] GCC started using __flt128_t when __float128 exists but _Float128 does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299 --- Comment #4 from Tymi --- Why not check for __clang__ and fallback to a compatible solution then?
[Bug target/120008] RFE: x86: explicit compiler support for SMAP stac/clac (possibly via __attribute__((user))) or similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120008 --- Comment #3 from Andrew Pinski --- (In reply to H. Peter Anvin from comment #2) > Could you please clarify why you think this is not a good idea? Because it is only specific to x86 and more over it is only specific to not userland. folks will be using it in userland and will complain about it not working. Plus I don't see why inline-asm here or an intrinsics wouldn't be better than attributes.
[Bug libstdc++/120299] GCC started using __flt128_t when __float128 exists but _Float128 does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299 --- Comment #7 from Andrew Pinski --- (In reply to Tymi from comment #6) > so it's a godbolt (compiler explorer) bug...? No, just godbolt build happened between the 2 commits.
[Bug libstdc++/120299] GCC started using __flt128_t when __float128 exists but _Float128 does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299 --- Comment #6 from Tymi --- so it's a godbolt (compiler explorer) bug...?
[Bug libstdc++/120299] GCC started using __flt128_t when __float128 exists but _Float128 does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299 --- Comment #8 from Tymi --- (In reply to Andrew Pinski from comment #7) > (In reply to Tymi from comment #6) > > so it's a godbolt (compiler explorer) bug...? > > No, just godbolt build happened between the 2 commits. Can we someone force/ask godbolt to rebuild now?
[Bug fortran/85750] [12/13/14/15/16 Regression] Default initialization of derived type array missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85750 --- Comment #15 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d31ab498b12ebbe4f50acb2aa240ff92c73f310c commit r16-669-gd31ab498b12ebbe4f50acb2aa240ff92c73f310c Author: Harald Anlauf Date: Thu May 15 21:07:07 2025 +0200 Fortran: default-initialization and functions returning derived type [PR85750] Functions with non-pointer, non-allocatable result and of derived type did not always get initialized although the type had default-initialization, and a derived type component had the allocatable or pointer attribute. Rearrange the logic when to apply default-initialization. PR fortran/85750 gcc/fortran/ChangeLog: * resolve.cc (resolve_symbol): Reorder conditions when to apply default-initializers. gcc/testsuite/ChangeLog: * gfortran.dg/alloc_comp_auto_array_3.f90: Adjust scan counts. * gfortran.dg/alloc_comp_class_3.f03: Remove bogus warnings. * gfortran.dg/alloc_comp_class_4.f03: Likewise. * gfortran.dg/allocate_with_source_14.f03: Adjust scan count. * gfortran.dg/derived_constructor_comps_6.f90: Likewise. * gfortran.dg/derived_result_5.f90: New test.
[Bug libstdc++/120299] GCC started using __flt128_t when __float128 exists but _Float128 does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299 --- Comment #9 from Andrew Pinski --- (In reply to Tymi from comment #8) > (In reply to Andrew Pinski from comment #7) > > (In reply to Tymi from comment #6) > > > so it's a godbolt (compiler explorer) bug...? > > > > No, just godbolt build happened between the 2 commits. > > Can we someone force/ask godbolt to rebuild now? godbolt rebuilds once a day and will rebuild tonight. Or you could force to use gcc 15.1.0's libstdc++ with clang if you want something more stable.
