[Bug sanitizer/120475] vector is 60x slower with ASan detect_stack_use_after_return=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120475 Andrew Pinski changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=110835, | |https://github.com/google/s | |anitizers/issues/1483 | CC||dodji at gcc dot gnu.org, ||dvyukov at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||kcc at gcc dot gnu.org Component|c++ |sanitizer --- Comment #1 from Andrew Pinski --- Maybe fixed by r15-7218-g13d97160117554 . Can you test GCC 15.1.0?
[Bug sanitizer/120475] vector is 60x slower with ASan detect_stack_use_after_return=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120475 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Maybe fixed by r15-7218-g13d97160117554 . > > Can you test GCC 15.1.0? Or 14.3.0 since that patch was backported; r14-11253-g946c17e456d3a3 It might be already fixed for GCC 13.4.0 (backport by r13-9350-gaac7bb773f7d1c) too.
[Bug sanitizer/120475] vector is 60x slower with ASan detect_stack_use_after_return=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120475 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-05-30 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1
[Bug fortran/27436] gfortran: Abort compiling if there are insufficient data descriptors in format after reversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27436 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #6 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #3) > (In reply to comment #1) > > Adding to my list > > Do you mean that you assign this PR to you? Meaning wait 15 years before doing anything. ;)
[Bug c++/120475] New: vector is 60x slower with ASan detect_stack_use_after_return=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120475
Bug ID: 120475
Summary: vector is 60x slower with ASan
detect_stack_use_after_return=1
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dani at danielbertalan dot dev
Target Milestone: ---
When compiled with -O2 -fsanitize=address -fsanitize=undefined, the code below
runs 60 times slower if ASAN_OPTIONS=detect_stack_use_after_return=1 is set
(default since GCC 13) than with stack use after return checking disabled.
Benchmark 1: env ASAN_OPTIONS=detect_stack_use_after_return=1 ./bug
Time (mean ± σ): 10.443 s ± 0.846 s[User: 10.432 s, System: 0.009 s]
Range (min … max): 10.056 s … 12.677 s10 runs
Benchmark 2: env ASAN_OPTIONS=detect_stack_use_after_return=0 ./bug
Time (mean ± σ): 167.9 ms ± 3.7 ms[User: 161.7 ms, System: 5.9 ms]
Range (min … max): 161.5 ms … 174.1 ms18 runs
Summary
env ASAN_OPTIONS=detect_stack_use_after_return=0 ./bug ran
62.20 ± 5.22 times faster than env
ASAN_OPTIONS=detect_stack_use_after_return=1 ./bug
GCC version: g++ (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
Target: aarch64-linux-gnu
The benchmark numbers are from an AWS instance with the Graviton 2 processor
---
// Godbolt: https://godbolt.org/z/5jGc7rc9v
#include
#include
[[gnu::noinline, gnu::noipa]] void test(std::vector &a) {
const int M = 2e6 + 10;
std::vector isprime(M+1, true);
isprime[0] = isprime[1] = false;
for (int i = 2; i <= M; i++) {
if (isprime[i] && (long long) i*i <= M) {
for (int j = i*i; j <= M; j+=i) isprime[j] = false;
}
}
int ans = 1;
std::vector even, res;
for (int i = 0; i < a.size(); i++) {
if (a[i]%2) even.push_back(a[i]);
}
res = {a[0]};
for (int e : a) {
if (ans < 2 && !(e%2)) {
for (int& j : even) {
if (isprime[e+j]) {
ans = 2;
res.clear(); res.push_back(e); res.push_back(j);
break;
}
}
}
}
std::cout << ans << "\n";
for (const int& e : res) std::cout << e << " ";
}
int main() {
std::vector v = {2,3};
test(v);
}
perf shows that 98% of the time is spent in __asan_stack_malloc_2, which is
called from vector::operator[]. It looks like that function gets big
enough for it not to be considered for inlining under -O2.
[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 Jerry DeLisle changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #11 from Jerry DeLisle --- I can reproduce that here. $ gfc badfmt.f90 $ ./a.out ioerr =5006 value = + Definately not right. This is some different Issue.
[Bug rtl-optimization/111901] Apparently bogus CSE of inline asm with memory clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
--- Comment #8 from Uroš Bizjak ---
Compiling the testcase for aarch64-linux-gnu (-O2 -funroll-all-loops) still
performs CSE, despite the patch:
_.c.325r.reload:
6: {x0:SI=asm_operands;clobber [scratch];}
8: {x2:SI=asm_operands;clobber [scratch];}
10: {x1:SI=asm_operands;clobber [scratch];}
12: {x3:SI=asm_operands;clobber [scratch];}
13: x1:SI=x1:SI+x3:SI
14: x0:SI=x0:SI+x2:SI
15: NOTE_INSN_DELETED
20: x0:SI=x1:SI+x0:SI
21: use x0:SI
_.c.326r.postreload:
6: {x0:SI=asm_operands;clobber [scratch];}
8: {x2:SI=asm_operands;clobber [scratch];}
10: {x1:SI=asm_operands;clobber [scratch];}
12: {x3:SI=asm_operands;clobber [scratch];}
13: x1:SI=x1:SI+x3:SI
14: x0:SI=x1:SI<-- **here**
15: NOTE_INSN_DELETED
20: x0:SI=x1:SI+x0:SI
21: use x0:SI
which suggests problems deeper in the CSE library.
[Bug rtl-optimization/111901] Apparently bogus CSE of inline asm with memory clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901 Uroš Bizjak changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org, ||law at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #9 from Uroš Bizjak --- Adding some CCs.
[Bug fortran/27436] gfortran: Abort compiling if there are insufficient data descriptors in format after reversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27436
--- Comment #7 from Jerry DeLisle ---
Currently.
! From PR27436
write(*,'(abc)') n ! We throw a compile time error here.
write(10,"(i7,(' abcd'))") n, n ! We throw a run time error here.
10 print *, "Hello World!"
end
Comment the first statement is gives:
At line 3 of file test2.f90 (unit = 10, file = 'fort.10')
Fortran runtime error: Insufficient data descriptors in format after reversion
If I find any easy tweak to give a compile time warning on that second write
example I may do so. If not, I would prefer we close this one.
[Bug testsuite/120457] [16 Regression] gcc.dg/vect/pr79920.c fail starting with r16-924-g1bc5b47f5b06dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120457
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Last reconfirmed||2025-05-30
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |16.0
Keywords||missed-optimization
Summary|gcc.dg/vect/pr79920.c fail |[16 Regression]
|starting with |gcc.dg/vect/pr79920.c fail
|r16-924-g1bc5b47f5b06dc |starting with
||r16-924-g1bc5b47f5b06dc
--- Comment #3 from Richard Biener ---
So do we now no longer put t32[ip_1][0] and t32[ip_1][2] into a single DR
group?
IIRC power has V2DF but nothing larger, so those two elements will never get
loaded together, meaning the heuristic makes some sense.
t.c:14:7: note: Detected single element interleaving *_4 step 24
t.c:14:7: note: Detected single element interleaving *_10 step 24
But what happens is that we end up lowering this into a vector interleaving
scheme that covers the other access anyway:
t.c:14:7: note: node 0x3dda5b0 (max_nunits=2, refcnt=2) vector(2) double
t.c:14:7: note: op: VEC_PERM_EXPR
t.c:14:7: note: stmt 0 _5 = *_4;
t.c:14:7: note: lane permutation { 0[0] }
t.c:14:7: note: children 0x3dda910
t.c:14:7: note: node 0x3dda910 (max_nunits=1, refcnt=1) vector(2) double
t.c:14:7: note: op: VEC_PERM_EXPR
t.c:14:7: note: stmt 0 _5 = *_4;
t.c:14:7: note: stmt 1 _5 = *_4;
t.c:14:7: note: lane permutation { 0[0] 0[0] }
t.c:14:7: note: children 0x3dda880
t.c:14:7: note: node 0x3dda880 (max_nunits=2, refcnt=2) vector(2) double
t.c:14:7: note: op template: _5 = *_4;
t.c:14:7: note: stmt 0 _5 = *_4;
t.c:14:7: note: stmt 1 ---
t.c:14:7: note: stmt 2 ---
but then decide
t.c:14:7: note: === vect_slp_analyze_operations ===
t.c:14:7: note: ==> examining statement: _5 = *_4;
t.c:14:7: missed: single-element interleaving not supported for not adjacent
vector loads
that would get us a elementwise accesses if we'd have just a single lane,
but the lowering above wrecked that path
t.c:15:31: missed: not vectorized: relevant stmt not supported: _5 = *_4;
t.c:14:7: note: unsupported SLP instance starting from: t33[ip_1_46][i_0_47]
= _14;
t.c:14:7: missed: unsupported SLP instances
this is a heuristic as well:
/* If this is single-element interleaving with an element
distance that leaves unused vector loads around fall back
to elementwise access if possible - we otherwise least
create very sub-optimal code in that case (and
blow up memory, see PR65518). */
if (loop_vinfo
&& single_element_p
&& (*memory_access_type == VMAT_CONTIGUOUS
|| *memory_access_type == VMAT_CONTIGUOUS_REVERSE)
&& maybe_gt (group_size, TYPE_VECTOR_SUBPARTS (vectype)))
we can extend that to be a permute lowering heuristic as well.
[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 --- Comment #13 from Jerry DeLisle --- (In reply to Walter Spector from comment #12) > > Definately not right. > > > > This is some different Issue. > > If it would help, I'd be happy to submit another PR. No need. I do have an idea why this is happening. It is a letent 'feature' ;)
[Bug target/120476] New: LoongArch: -mtune=la664 is pessimizing even on LA664
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120476 Bug ID: 120476 Summary: LoongArch: -mtune=la664 is pessimizing even on LA664 Product: gcc Version: 15.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at gcc dot gnu.org Target Milestone: --- Per https://github.com/loongson-community/discussions/issues/94#issuecomment-2919912764: Spec int 2017 rate-1 with GCC 15.1.0 on 3C6000: -O3 -march=la464: 4.49 -O3 -march=la664: 4.40 -O3: 4.49 benchmark la464 la664 only O3 perlbench 3.893.923.92 gcc 4.154.124.13 mcf 4.254.234.20 omnetpp 4.524.334.52 xalancbmk 3.473.663.46 x2648.868.539.09 deepsjeng 3.263.233.25 leela 3.213.203.20 exchange2 12.110.412.2 xz 2.732.722.75 And openssl-3.5.0 "openssl speed sha512" is substantially slower with -mtune=la664 on 3A6000.
[Bug c++/118074] [coroutine] Initialize return value before destruction of coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118074 --- Comment #9 from Weibo He --- Thank you for your work. I noticed the heap-use-after-free issue might still be present? https://godbolt.org/z/79bvTfWe5
[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 --- Comment #12 from Walter Spector --- > Definately not right. > > This is some different Issue. If it would help, I'd be happy to submit another PR.
[Bug ipa/120295] [15/16 Regression] Wrong code on -O3 for trunk version (live code is wrongly eliminated) since r15-6294-g96fb71883d438b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120295 --- Comment #11 from GCC Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:0b004c92f5ea239936a403a2a757e12ca82ce6d8 commit r16-960-g0b004c92f5ea239936a403a2a757e12ca82ce6d8 Author: Martin Jambor Date: Thu May 29 16:32:04 2025 +0200 ipa: When inlining, don't combine PT JFs changing signedness (PR120295) In GCC 15 we allowed jump-function generation code to skip over a type-cast converting one integer to another as long as the latter can hold all the values of the former or has at least the same precision. This works well for IPA-CP where we do then evaluate each jump function as we propagate values and value-ranges. However, the test-case in PR 120295 shows a problem with inlining, where we combine pass-through jump-functions so that they are always relative to the function which is the root of the inline tree. Unfortunately, we are happy to combine also those with type-casts to a different signedness which makes us use sign zero extension for the expected value ranges where we should have used sign extension. When the value-range which then leads to wrong insertion of a call to builtin_unreachable is being computed, the information about an existence of a intermediary signed type has already been lost during previous inlining. This patch simply blocks combining such jump-functions so that it is back-portable to GCC 15. Once we switch pass-through jump functions to use a vector of operations rather than having room for just one, we will be able to address this situation with adding an extra conversion instead. gcc/ChangeLog: 2025-05-19 Martin Jambor PR ipa/120295 * ipa-prop.cc (update_jump_functions_after_inlining): Do not combine pass-through jump functions with type-casts changing signedness. gcc/testsuite/ChangeLog: 2025-05-19 Martin Jambor PR ipa/120295 * gcc.dg/ipa/pr120295.c: New test.
[Bug c++/120453] [16 regression] qcoro fails to build its tests (error: use of deleted function ... is implicitly deleted because the default definition would be ill-formed) since r16-773-ge06555a40c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120453 --- Comment #15 from Jason Merrill --- (In reply to Iain Sandoe from comment #14) > * If we add the non-coroutine simulation of the ramp, then clang-20 also > complains - but with a different diagnostic: > > ":97:10: error: call to implicitly-deleted copy constructor of > 'LazyTask' >97 | return Gro; So they complain about the deleted copy constructor rather than the deleted move constructor. That's probably this bit in joust: /* Prefer a non-deleted function over an implicitly deleted move constructor or assignment operator. This differs slightly from the wording for issue 1402 (which says the move op is ignored by overload resolution), but this way produces better error messages. */
[Bug c++/117785] [C++26] P3068R5 - constexpr exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785 Jakub Jelinek changed: What|Removed |Added Attachment #61546|0 |1 is obsolete|| --- Comment #21 from Jakub Jelinek --- Created attachment 61549 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61549&action=edit gcc16-pr117785-wip.patch Further progress.
[Bug c/120381] [14/15/16 Regression] internal compiler error: in composite_type_internal, at c/c-typeck.cc:848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120381 --- Comment #4 from uecker at gcc dot gnu.org --- Created attachment 61548 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61548&action=edit patch for trunk
[Bug modula2/120474] InOut buffering should flush the WriteLn before the Read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120474 Gaius Mulley changed: What|Removed |Added Last reconfirmed||2025-05-29 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Gaius Mulley --- Confirmed.
[Bug libstdc++/99832] std::chrono::system_clock::to_time_t needs ABI tag for 32-bit time_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
--- Comment #15 from Jonathan Wakely ---
I suppose another way to resolve this would be to just mark that function
[[__gnu__::__always_inline__]].
That would require no config changes at all, we could do it unconditionally.
Or we could do:
// Map to C API
#ifdef __USE_TIME64_REDIRECTS
[[__gnu__::__always_inline__]]
#endif
static std::time_t
to_time_t(const time_point& __t) noexcept
{
return std::time_t(duration_cast
(__t.time_since_epoch()).count());
}
[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 --- Comment #10 from Walter Spector --- My bad. Didn't have LD_LIBRARY_PATH set right... $ ls -l $LD_LIBRARY_PATH/*gf* -rw-r--r-- 1 root root 21336066 May 29 07:59 /usr/local/lib64/libgfortran.a -rwxr-xr-x 1 root root 977 May 29 07:59 /usr/local/lib64/libgfortran.la lrwxrwxrwx 1 root root 20 May 29 07:59 /usr/local/lib64/libgfortran.so -> libgfortran.so.5.0.0 lrwxrwxrwx 1 root root 20 May 29 07:59 /usr/local/lib64/libgfortran.so.5 -> libgfortran.so.5.0.0 -rwxr-xr-x 1 root root 11500400 May 29 07:59 /usr/local/lib64/libgfortran.so.5.0.0 -rw-r--r-- 1 root root 278 May 29 07:59 /usr/local/lib64/libgfortran.spec $ So now I get an error code from iostat - which is good. But it is interesting that the second write statement doesn't abend. It prints the string 'value =', and a '+' sign. Then the program completes normally. (Exit code 0.) As if the iostat= didn't reset something inside some internal I/O data structure. So when the print, and then the second write came along, it doesn't provide the error. $ gfortran -std=f95 badfmt2.f90 $ ./a.out ioerr =5006 value = + $ If I remove the iostat= from the first write, as you did, I get an immediate abend: $ ./a.out At line 7 of file badfmt2.f90 (unit = 6, file = 'stdout') Fortran runtime error: Missing comma between descriptors (AI5) ^ Error termination. Backtrace: #0 0x7f26028390fa in parse_format_list at ../../../gcc-trunk/libgfortran/io/format.c:1240 #1 0x7f260284c427 in data_transfer_init at ../../../gcc-trunk/libgfortran/io/transfer.c:3298 #2 0x4011ce in ??? #3 0x40134e in ??? #4 0x7f26021ff082 in __libc_start_main at ../csu/libc-start.c:308 #5 0x4010bd in ??? #6 0x in ??? $
[Bug c++/120458] module-name does not allow non-ASCII characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120458 Nathaniel Shead changed: What|Removed |Added CC||nshead at gcc dot gnu.org --- Comment #4 from Nathaniel Shead --- Looks like the issue is in libcody; we hit gcc/libcody/buffer.cpp:295 when receiving the module name: if (c < S2C(u8" ") || c >= 0x7f) goto malformed; which quite obviously doesn't support the non-ASCII subset of UTF-8. Reading through https://github.com/urnathan/libcody?tab=readme-ov-file#packet-encoding I suppose it sounds like it expects these characters to have been escaped somehow, though reading should still work I think?
[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 --- Comment #7 from Walter Spector --- Confirmed that the compiler now diagnoses the missing commas. Thanks! As noted in Comment 1, there is no message at run-time for run-time formats: $ cat badfmt2.f90 program badfmt implicit none character(10):: fmt = "(AI5)" ! Not parameter, so not examined at compile time integer :: ioerr write (*, fmt, iostat=ioerr) 'value =', 42 print *, 'ioerr =', ioerr write (*, fmt) 'value =', 43 end program badfmt $ $ gfortran badfmt2.f90 $ ./a.out value = 42 ioerr = 0 value = 43 $ $ gfortran --std=f95 badfmt2.f90 $ ./a.out value = 42 ioerr = 0 value = 43 $ $ gfortran --version GNU Fortran (GCC) 16.0.0 20250529 (experimental) Copyright (C) 2025 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $
[Bug c++/113563] Rejects capture of `this` in C++23 `this auto` lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org
[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 --- Comment #8 from Jerry DeLisle --- (In reply to Walter Spector from comment #7) > Confirmed that the compiler now diagnoses the missing commas. Thanks! > After taking out the iostat so I could see the error message I am getting the following here: $ gfc -std=f95 test.f90 $ ./a.out At line 7 of file newby.f90 (unit = 6, file = 'stdout') Fortran runtime error: Missing comma between descriptors (AI5) ^ $ gfc -std=legacy test.f90 $ ./a.out value = 42 value = 43 Maybe you are linking in the wrong libgfortran. Set LD_LIBRARY_PATH to point to the correct place.
[Bug c++/120453] [16 regression] qcoro fails to build its tests (error: use of deleted function ... is implicitly deleted because the default definition would be ill-formed) since r16-773-ge06555a40c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120453 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #17 from Iain Sandoe --- so fixed on trunk.
[Bug c++/118074] [coroutine] Initialize return value before destruction of coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118074 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2025-05-29 --- Comment #8 from Iain Sandoe --- I believe that this is fixed on trunk (as a consequence of fixing PR119916 / CWG2563). Please confirm (I have tested your example, below - but perhaps you have some larger case?)
[Bug rtl-optimization/99015] [12/13 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99015 --- Comment #15 from GCC Commits --- The releases/gcc-13 branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:af73c8bf5168848275bf909ee44fbb8f4973438f commit r13-9726-gaf73c8bf5168848275bf909ee44fbb8f4973438f Author: Vladimir N. Makarov Date: Thu May 29 15:26:30 2025 -0400 [LRA]: Backporting solutions for PR112918 and PR113354 to solve PR99015 Patches for PR112918 and PR11354 depend on each other and can not be clearly applied to gcc-13 branch. So patches were modified and combined. gcc/ChangeLog: PR rtl-optimization/99015 * lra-constraints.cc (enough_allocatable_hard_regs_p): Extract from in_class_p. (in_class_p): Use it with added conditions. (process_alt_operands): Try to change class too. (curr_insn_transform): Pass true to in_class_p for reg operand win. Spill pseudo only used in the insn if the corresponding operand does not require hard register anymore.
[Bug rtl-optimization/99015] [12/13 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99015 --- Comment #16 from Vladimir Makarov --- I've remembered that the patch for PR112918 triggered a hidden bug on mips. So I added code fixing this bug too to this PR patch. The new patch was successfully bootstrapped and tested on amd64, arm64, and ppc64le.
[Bug modula2/120474] New: InOut buffering should flush the WriteLn before the Read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120474
Bug ID: 120474
Summary: InOut buffering should flush the WriteLn before the
Read
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: gaius at gcc dot gnu.org
Target Milestone: ---
forwarded from the gm2 mailing list:
===
MODULE essaiget;
FROM InOut IMPORT
WriteString, Read, WriteLn;
VAR
ch : CHAR ;
BEGIN
WriteString("Essai de get");
WriteLn;
Read(ch);
WriteString("Fin de l'Essai de get");
WriteLn;
END essaiget.
===
I got this: (I entered the "a" character.)
===
$ gm2 -O3 essaiget.mod -o essaiget
$ ./essaiget
Essai de geta
Fin de l'Essai de get
[Bug c++/99858] Wrong throw-expression behaviour with reference to pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99858 --- Comment #5 from Andrew Pinski --- I think this is a dup of bug 23257.
[Bug c++/113563] Rejects capture of `this` in C++23 `this auto` lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563 --- Comment #12 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2047aa4ce2ed9976fb36e984b43864fcd6f3a65d commit r16-970-g2047aa4ce2ed9976fb36e984b43864fcd6f3a65d Author: Jason Merrill Date: Thu May 29 12:36:23 2025 -0400 c++: xobj lambda 'this' capture [PR113563] Various places were still making assumptions that we could get to the 'this' capture through current_class_ref in a lambda op(), which is incorrect for an explicit object op(). PR c++/113563 gcc/cp/ChangeLog: * lambda.cc (build_capture_proxy): Check pointerness of the member, not the proxy type. (lambda_expr_this_capture): Don't assume current_class_ref. (nonlambda_method_basetype): Likewise. * semantics.cc (finish_non_static_data_member): Don't assume TREE_TYPE (object) is set. (finish_this_expr): Check current_class_type for lambda, not current_class_ref. gcc/testsuite/ChangeLog: * g++.dg/cpp23/explicit-obj-lambda16.C: New test.
[Bug c++/113563] Rejects capture of `this` in C++23 `this auto` lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563 --- Comment #13 from Jason Merrill --- Fixed for 16 so far.
[Bug sanitizer/120471] -fsanitize=undefined causes read of uninitialized variable when accessing element in an array at -O0 level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471 --- Comment #1 from xiaohuba2021 --- sorry, there is a blank line on the top of the source code. so line 5 should actually be `volatile int v = (ll % 2 ? b : ib)[c % 3];`
[Bug libstdc++/120465] std::erase_if for std::flat_map calls predicate with incorrect type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120465 --- Comment #4 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:589b27ec5769410e036df57645ff1eb7c765f692 commit r16-957-g589b27ec5769410e036df57645ff1eb7c765f692 Author: Patrick Palka Date: Thu May 29 10:11:57 2025 -0400 libstdc++: Fix tuple/pair confusion with std::erase_if(flat_map) [PR120465] std::erase_if for flat_map/multimap is implemented via ranges::erase_if over a zip_view of the keys and values, the value_type of which is a tuple, but the given predicate needs to be called with a pair (flat_map's value_type). So use a projection to convert the tuple into a suitable pair. PR libstdc++/120465 libstdc++-v3/ChangeLog: * include/std/flat_map (_Flat_map_impl::_M_erase_if): Use a projection with ranges::remove_if to pass a pair instead of a tuple to the predicate. * testsuite/23_containers/flat_map/1.cc (test07): Strengthen to expect the argument passed to the predicate is a pair. * testsuite/23_containers/flat_multimap/1.cc (test07): Likewise. Co-authored-by: Jonathan Wakely Reviewed-by: Tomasz KamiÅski Reviewed-by: Jonathan Wakely
[Bug sanitizer/120471] -fsanitize=undefined causes read of uninitialized variable when accessing element in an array at -O0 level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471 --- Comment #3 from Sam James --- (In reply to Xi Ruoyao from comment #2) > I cannot reproduce it locally, nor on godbolt: > https://godbolt.org/z/rxf8Es1n5. Try the C++ FE.
[Bug sanitizer/120471] -fsanitize=undefined causes read of uninitialized variable when accessing element in an array at -O0 level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471 --- Comment #4 from xiaohuba2021 --- (In reply to Xi Ruoyao from comment #2) > I cannot reproduce it locally, nor on godbolt: > https://godbolt.org/z/rxf8Es1n5. switch the language to c++ successfully reproduce it: https://godbolt.org/z/z6WhKKa74
[Bug c++/119864] [15/16 Regression][modules] ICE with -fmodules and omp reduction of UDT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119864
--- Comment #10 from Nathaniel Shead ---
(In reply to Pilar Latiesa from comment #9)
> (In reply to Nathaniel Shead from comment #4)
>
> > The assertion is thrown when streaming the generated function "omp declare
> > reduction Op" because this is a DECL_LOCAL_DECL_P function but isn't on the
> > BLOCK of sum, so we didn't stream it by value when we were supposed to.
>
> Is the BLOCK incorrectly set or does it lack a DECL_CONTEXT at all?
>
> Thanks
I believe the BLOCK is incorrect.
(gdb) p decl->decl_minimal.context
$1 =
It should have been streamed while streaming 'sum' in 'trees_out::core_vals':
/* Miscellaneous common nodes. */
case BLOCK:
if (state)
{
state->write_location (*this, t->block.locus);
state->write_location (*this, t->block.end_locus);
}
/* DECL_LOCAL_DECL_P decls are first encountered here and
streamed by value. */
for (tree decls = t->block.vars; decls; decls = DECL_CHAIN (decls))
{
if (VAR_OR_FUNCTION_DECL_P (decls)
&& DECL_LOCAL_DECL_P (decls))
{
/* Make sure this is the first encounter, and mark for
walk-by-value. */
gcc_checking_assert (!TREE_VISITED (decls)
&& !DECL_TEMPLATE_INFO (decls));
mark_by_value (decls);
}
tree_node (decls);
}
tree_node (NULL_TREE);
But
(gdb) pt $1->decl_common.initial->block.vars
template-info
args
readonly constant visited decl
index 0 level 1 orig_level 1>>>
full-name "struct T"
no-binfo use_template=1 interface-unknown
reference_to_this chain >
used visited tree_2 tree_3 tree_6 read decl_5 VOID
/home/wreien/m/f.cpp:16:6
align:8 warn_if_not_align:0 context
initial
module 0:p1 purview attached exported>
Unless there's some other part of the function that this omp reductions are
attached to we should be streaming by value first.
[Bug c++/120453] [16 regression] qcoro fails to build its tests (error: use of deleted function ... is implicitly deleted because the default definition would be ill-formed) since r16-773-ge06555a40c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120453 --- Comment #16 from GCC Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:217b7f655227a52e5fe26729baa09dc6083ed577 commit r16-961-g217b7f655227a52e5fe26729baa09dc6083ed577 Author: Iain Sandoe Date: Thu May 29 11:00:18 2025 +0100 c++, coroutines: Fix identification of coroutine ramps [PR120453]. The existing implementation, incorrectly, tried to use DECL_RAMP_FN in check_return_expr to determine if we are handling a ramp func. However, that query is only set for the resume/destroy functions. Replace the use of DECL_RAMP_FN with a new query. PR c++/120453 gcc/cp/ChangeLog: * cp-tree.h (DECL_RAMP_P): New. * typeck.cc (check_return_expr): Use DECL_RAMP_P instead of DECL_RAMP_FN. gcc/testsuite/ChangeLog: * g++.dg/coroutines/pr120453.C: New test. Signed-off-by: Iain Sandoe
[Bug libgomp/93226] OpenACC 2.6: acc_memcpy_device runtime function missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93226
--- Comment #3 from GCC Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:f4aa6b5a8d63050f5d61fcec222ed87be4c0a266
commit r16-971-gf4aa6b5a8d63050f5d61fcec222ed87be4c0a266
Author: Tobias Burnus
Date: Thu May 29 22:47:06 2025 +0200
libgomp: Add OpenACC's acc_memcpy_device{,_async} routines [PR93226]
libgomp/ChangeLog:
PR libgomp/93226
* libgomp-plugin.h (GOMP_OFFLOAD_openacc_async_dev2dev): New
prototype.
* libgomp.h (struct acc_dispatch_t): Add dev2dev_func.
(gomp_copy_dev2dev): New prototype.
* libgomp.map (OACC_2.6.1): New; add acc_memcpy_device{,_async}.
* libgomp.texi (acc_memcpy_device): New.
* oacc-mem.c (memcpy_tofrom_device): Change to take from/to
device boolean; use memcpy not memmove; add early return if
size == 0 or same device + same ptr.
(acc_memcpy_to_device, acc_memcpy_to_device_async,
acc_memcpy_from_device, acc_memcpy_from_device_async): Update.
(acc_memcpy_device, acc_memcpy_device_async): New.
* openacc.f90 (acc_memcpy_device, acc_memcpy_device_async):
Add interface.
* openacc_lib.h (acc_memcpy_device, acc_memcpy_device_async):
Likewise.
* openacc.h (acc_memcpy_device, acc_memcpy_device_async): Add
prototype.
* plugin/plugin-gcn.c (GOMP_OFFLOAD_openacc_async_host2dev):
Update comment.
(GOMP_OFFLOAD_openacc_async_dev2host): Update call.
(GOMP_OFFLOAD_openacc_async_dev2dev): New.
* plugin/plugin-nvptx.c (cuda_memcpy_dev_sanity_check): New.
(GOMP_OFFLOAD_dev2dev): Call it.
(GOMP_OFFLOAD_openacc_async_dev2dev): New.
* target.c (gomp_copy_dev2dev): New.
(gomp_load_plugin_for_device): Load dev2dev and async_dev2dev.
* testsuite/libgomp.oacc-c-c++-common/acc_memcpy_device-1.c: New
test.
* testsuite/libgomp.oacc-fortran/acc_memcpy_device-1.f90: New test.
[Bug rtl-optimization/120469] [SH] Delay slot optimization opportunity missed with atomic writes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120469 --- Comment #3 from Jeffrey A. Law --- In general, I wouldn't recommend it. While I no longer work on delay slot architectures, the basic guidance I would give would be anything that is not single cycle doesn't belong in a delay slot. If I were to make exceptions it would be for simple (ie non-atomic) loads/stores.
[Bug libgomp/93226] OpenACC 2.6: acc_memcpy_device runtime function missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93226 Tobias Burnus changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Tobias Burnus --- Should be FIXED (GCC 16 mainline)
[Bug c++/119864] [15/16 Regression][modules] ICE with -fmodules and omp reduction of UDT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119864 --- Comment #11 from Pilar Latiesa --- Thanks Nathaniel I had a look at semantics.cc but I'm definitely not clever enough to understand. I observe, however, that there are no BLOCK_VARS (...) = ...; statements in finish_omp_reduction_clause.
[Bug c++/120273] [15/16 regression] ICE when building corral since r15-3148-g6303cd7e41546e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120273 Iain Sandoe changed: What|Removed |Added Status|NEW |ASSIGNED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2025-May/685 ||056.html Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #11 from Iain Sandoe --- patch posted
[Bug c/68612] Const-compatibility in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68612 uecker at gcc dot gnu.org changed: What|Removed |Added CC||uecker at gcc dot gnu.org --- Comment #10 from uecker at gcc dot gnu.org --- (In reply to lavr from comment #9) > GCC14 is breaking builds now, because the warning has been promoted to > error, with this problem still unresolved. There is some proposal to also change the rules for ISO C. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3449.pdf This proposes even more extensive changes, but I think adding a flag for the C++ rules would be reasonable.
[Bug c/120380] [14/15/16 Regression] internal compiler error: error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120380 --- Comment #4 from uecker at gcc dot gnu.org --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2025-May/685120.html
[Bug c/120381] [14/15/16 Regression] internal compiler error: in composite_type_internal, at c/c-typeck.cc:848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120381 --- Comment #5 from uecker at gcc dot gnu.org --- Turns out one can trigger this also using statement expressions: https://godbolt.org/z/3M8en31zd PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2025-May/685119.html
[Bug sanitizer/120471] [12/13/14/15/16 regression] -fsanitize=undefined causes read of uninitialized variable when accessing element in an array at -O0 level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471 Sam James changed: What|Removed |Added Known to fail||10.1.0, 15.1.0 Summary|-fsanitize=undefined causes |[12/13/14/15/16 regression] |read of uninitialized |-fsanitize=undefined causes |variable when accessing |read of uninitialized |element in an array at -O0 |variable when accessing |level |element in an array at -O0 ||level Target Milestone|--- |12.5 Known to work||9.5.0 Keywords||needs-bisection --- Comment #8 from Sam James --- Let's worry about the wrong-code and call it a regression for that.
[Bug rtl-optimization/120469] [SH] Delay slot optimization opportunity missed with atomic writes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120469 --- Comment #1 from Andrew Pinski --- I think this is by design, relaxed atomic stores on the rtl level are modeled like volatile stores. And volatile stores are NOT put in delay slots either.
[Bug libstdc++/120472] New: Wtype-limits warning in semaphore_base.h on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120472 Bug ID: 120472 Summary: Wtype-limits warning in semaphore_base.h on Cygwin Product: gcc Version: 15.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: zmajeed at sbcglobal dot net Target Milestone: --- This is a follow-up to bug 120449, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120449 __platform_wait_t is unsigned long on Cygwin and causes type-limits warning in semaphore_base.h Testfile typelimits.cpp #include - With the fix from bug 120449 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120449#c6 g++ -c -Wtype-limits -std=c++20 -Wsystem-headers typelimits.cpp In file included from libstdc++-v3/include/bits/requires_hosted.h:31, from libstdc++-v3/include/semaphore:36, from typelimits.cpp:1: libstdc++-v3/include/bits/semaphore_base.h: In constructor ‘std::__atomic_semaphore::__atomic_semaphore(std::__detail::__platform_wait_t)’: semaphore_base.h:178:7: warning: comparison of unsigned expression in ‘>= 0’ is always true [-Wtype-limits] 178 | __glibcxx_assert(__count >= 0 && __count <= _S_max); - Warning could be fixed with something like __glibcxx_assert((__count > 0 || __count == 0) && __count <= _S_max); or also check for unsigned type __glibcxx_assert((is_unsigned_v || __count > 0 || __count == 0) && __count <= _S_max);
[Bug sanitizer/120471] -fsanitize=undefined causes read of uninitialized variable when accessing element in an array at -O0 level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471 Xi Ruoyao changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Xi Ruoyao --- (In reply to xiaohuba2021 from comment #4) > (In reply to Xi Ruoyao from comment #2) > > I cannot reproduce it locally, nor on godbolt: > > https://godbolt.org/z/rxf8Es1n5. > > switch the language to c++ successfully reproduce it: > https://godbolt.org/z/z6WhKKa74 Indeed. And it only reproduces with GCC 15, and does not reproduce with 14 or trunk. Maybe a dup of some recently fixed bug.
[Bug sanitizer/120471] -fsanitize=undefined causes read of uninitialized variable when accessing element in an array at -O0 level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471 --- Comment #6 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #5) > (In reply to xiaohuba2021 from comment #4) > > (In reply to Xi Ruoyao from comment #2) > > > I cannot reproduce it locally, nor on godbolt: > > > https://godbolt.org/z/rxf8Es1n5. > > > > switch the language to c++ successfully reproduce it: > > https://godbolt.org/z/z6WhKKa74 > > Indeed. And it only reproduces with GCC 15, and does not reproduce with 14 > or trunk. Nope, my network issue :(.
[Bug c/120380] [14/15/16 Regression] internal compiler error: error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120380 --- Comment #3 from uecker at gcc dot gnu.org --- Created attachment 61547 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61547&action=edit patch for trunk
[Bug c/120180] [OpenMP] ICE in C (c_parser_consume_token) / C++ cp_parser_skip_to_pragma_eol in error recovery for metadirective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120180 --- Comment #5 from GCC Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:65e0ed2310a1b0d1a3255583bbfb8a8d86c5aea5 commit r16-963-g65e0ed2310a1b0d1a3255583bbfb8a8d86c5aea5 Author: Sandra Loosemore Date: Sat May 24 03:21:18 2025 + OpenMP: Fix ICE in metadirective recovery after error [PR120180] It's not clear whether a metadirective in a loop nest is supposed to be valid, but GCC certainly shouldn't be ICE'ing after diagnosing it as an error. gcc/c/ChangeLog PR c/120180 * c-parser.cc (c_parser_omp_metadirective): Only consume the token if it is the expected close paren. gcc/cp/ChangeLog PR c/120180 * parser.cc (cp_parser_omp_metadirective): Only consume the token if it is the expected close paren. gcc/testsuite/ChangeLog PR c/120180 * c-c++-common/gomp/pr120180.c: New.
[Bug rtl-optimization/111901] Apparently bogus CSE of inline asm with memory clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901 Uroš Bizjak changed: What|Removed |Added Keywords||patch --- Comment #7 from Uroš Bizjak --- Patch at [1]. [1] https://gcc.gnu.org/pipermail/gcc-patches/2025-May/685106.html
[Bug c++/109283] Destructor of co_yield conditional argument called twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109283 --- Comment #8 from GCC Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:977fadd69776e2a8a6daca43e1c898bc4f87154d commit r16-969-g977fadd69776e2a8a6daca43e1c898bc4f87154d Author: Iain Sandoe Date: Thu May 29 15:45:29 2025 +0100 c++, coroutines: Make a check more specific [PR109283]. The check was intended to assert that we had visited contained ternary expressions with embedded co_awaits, but had been made too general - and therefore was ICEing on code that was actually OK. Fixed by checking specifically that no co_awaits embedded. PR c++/109283 gcc/cp/ChangeLog: * coroutines.cc (find_any_await): Only save the statement pointer if the caller passes a place for it. (flatten_await_stmt): When checking that ternary expressions have been handled, also check that they contain a co_await. gcc/testsuite/ChangeLog: * g++.dg/coroutines/pr109283.C: New test. Signed-off-by: Iain Sandoe
[Bug sanitizer/120471] -fsanitize=undefined causes read of uninitialized variable when accessing element in an array at -O0 level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471 Xi Ruoyao changed: What|Removed |Added Keywords||diagnostic, wrong-code --- Comment #7 from Xi Ruoyao --- The wrong-code started since GCC 10, and the bogus warning started since GCC 4.9. GCC <= 4.8 does not support sanitizer.
[Bug c++/120473] New: Pointers caught with pointer &var handler not modificable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120473
Bug ID: 120473
Summary: Pointers caught with pointer &var handler not
modificable
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
const char r[] = "hello";
const char *s[] = { &r[0], &r[3] };
const char **p = &s[0];
int
foo ()
{
try
{
throw p;
}
catch (const char **&x)
{
if (x != &s[0])
return 1;
++x;
if (x != &s[1])
return 2;
try
{
throw;
}
catch (const char **&y)
{
if (y != &s[1])
return 3;
}
}
return 0;
}
extern "C" int printf (const char *, ...);
int
main ()
{
printf ("%d\n", foo ());
}
prints 3 with gcc++ and 0 with clang++ and MSVC.
I would have thought that https://eel.is/c++draft/except#handle-16 would say
here that the changes should be done to the exception object. Is this related
to CWG388? Though in this case it is the same type case, i.e.
https://eel.is/c++draft/except#handle-3.1
rather than https://eel.is/c++draft/except#handle-3.3 or
https://eel.is/c++draft/except#handle-3.4
[Bug rtl-optimization/120469] [SH] Delay slot optimization opportunity missed with atomic writes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120469 --- Comment #2 from Paul Cercueil --- (In reply to Andrew Pinski from comment #1) > I think this is by design, relaxed atomic stores on the rtl level are > modeled like volatile stores. And volatile stores are NOT put in delay slots > either. Should volatile stores be put in delay slots?
[Bug c++/120473] Pointers caught with pointer &var handler not modificable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120473 --- Comment #1 from Jakub Jelinek --- Seems __cxa_begin_catch for all the pointers returns them by value rather than pointer to the pointer.
[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049 --- Comment #38 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:c69afa2f1bd7455457ab4e028a6bc51211b2dd20 commit r16-967-gc69afa2f1bd7455457ab4e028a6bc51211b2dd20 Author: Jerry DeLisle Date: Thu May 29 10:02:00 2025 -0700 Fortran: Make minor adjustment to error message. PR fortran/120049 gcc/fortran/ChangeLog: * check.cc(check_c_ptr_2): Rephrase error message for clarity. gcc/testsuite/ChangeLog: * gfortran.dg/c_f_pointer_tests_6.f90: Adjust dg-error directive.
[Bug sanitizer/120471] New: -fsanitize=undefined causes read of uninitialized variable when accessing element in an array at -O0 level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471
Bug ID: 120471
Summary: -fsanitize=undefined causes read of uninitialized
variable when accessing element in an array at -O0
level
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: xiaohuba2021 at 163 dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
The following code:
```
volatile int b[1], ib[1];
void build(int ll) {
volatile int c = 21;
volatile int v = (ll % 2 ? b : ib)[c % 3];
if (v != 0)
__builtin_abort();
return;
}
int main() {
build(1), build(2);
return 0;
}
```
will produce the following warning during runtime:
```
/app/example.cpp:5:43: runtime error: index 1 out of bounds for type 'int [1]'
/app/example.cpp:5:43: runtime error: load of address 0x0040413c with
insufficient space for an object of type 'volatile int'
0x0040413c: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00
^
```
Note that it also got a strange warning during compiling:
```
: In function 'void build(int)':
:5:40: warning: 'c.3' may be used uninitialized [-Wmaybe-uninitialized]
5 | volatile int v = (ll % 2 ? b : ib)[c % 3];
| ~~^~~
:5:38: note: 'c.3' was declared here
5 | volatile int v = (ll % 2 ? b : ib)[c % 3];
| ^
```
Compiled with `-O0 -fsanitize=undefined -Wall`.
-O1 hides it, but the warning still presents.
g++ -v:
```
x86-64 gcc 15.1 - cached (9476B) ~400 lines filtered
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-15.1.0/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-15.1.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging
--enable-libstdcxx-backtrace=yes --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,objc,obj-c++,go,d,m2,rust,cobol
--enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build-gcc--binutils-2.42
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.1.0 (Compiler-Explorer-Build-gcc--binutils-2.42)
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s'
'-masm=intel' '-fno-verbose-asm' '-S' '-O0' '-fsanitize=undefined' '-Wall' '-v'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' '/app/'
/opt/compiler-explorer/gcc-15.1.0/bin/../libexec/gcc/x86_64-linux-gnu/15.1.0/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-15.1.0/bin/../lib/gcc/x86_64-linux-gnu/15.1.0/
-D_GNU_SOURCE -quiet -dumpdir /app/ -dumpbase output.cpp -dumpbase-ext
.cpp -masm=intel -mtune=generic -march=x86-64 -g -O0 -Wall -version
-fdiagnostics-color=always -fno-verbose-asm -fsanitize=undefined -o
/app/output.s
GNU C++17 (Compiler-Explorer-Build-gcc--binutils-2.42) version 15.1.0
(x86_64-linux-gnu)
compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
```
[Bug sanitizer/120471] -fsanitize=undefined causes read of uninitialized variable when accessing element in an array at -O0 level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org Last reconfirmed||2025-05-29 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #2 from Xi Ruoyao --- I cannot reproduce it locally, nor on godbolt: https://godbolt.org/z/rxf8Es1n5.
[Bug c++/120473] Pointers caught with pointer &var handler not modificable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120473 --- Comment #2 from Andrew Pinski --- I think clang has a hack here to workaround Itanium ABI, see https://github.com/llvm/llvm-project/issues/55340#issuecomment-1152755112 Also see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23257#c5 . I think this is all a dup of bug 23257.
[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 --- Comment #9 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #8) > At line 7 of file newby.f90 (unit = 6, file = 'stdout') > Fortran runtime error: Missing comma between descriptors > (AI5) > ^ Oops, I copied the wrong one over from the terminal. $ gfc -std=f95 test.f90 jerry@quasar:~/dev/test/pr83282$ ./a.out At line 7 of file test.f90 (unit = 6, file = 'stdout') Fortran runtime error: Missing comma between descriptors (AI5) ^
[Bug c/115566] Arrays of character type initialized with parenthesized string literals shouldn't be diagnosed with -pedantic (at least in C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115566 --- Comment #9 from Halalaluyafail3 --- A recent paper N3457 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3547.pdf) if accepted would clearly allow this.
[Bug fortran/120470] gfortran -Wexternal-argument-mismatch produces compile error on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120470 Christopher Albert changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Christopher Albert --- Just confirmed that this is a duplicate. *** 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 Christopher Albert changed: What|Removed |Added CC||albert at tugraz dot at --- Comment #7 from Christopher Albert --- *** Bug 120470 has been marked as a duplicate of this bug. ***
[Bug libstdc++/108859] Exception thrown by std::filesystem::copy() is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108859
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2023-02-20 00:00:00 |2025-5-29
--- Comment #1 from Jonathan Wakely ---
#include
#include
#include
int main()
{
system("mkdir -p foo bar");
system("touch foo/file bar/file");
try {
std::filesystem::copy(std::filesystem::path("foo"),
std::filesystem::path("bar"),
std::filesystem::copy_options::recursive);
} catch (const std::filesystem::filesystem_error& e) {
std::cerr << e.what() << '\n';
}
}
This prints:
filesystem error: cannot copy: File exists [foo] [bar]
But the problem is that bar/file exists, not that bar exists.
This is because the throwing form of std::filesystem::copy just calls the
non-throwing form:
void
fs::copy(const path& from, const path& to, copy_options options)
{
error_code ec;
copy(from, to, options, ec);
if (ec)
_GLIBCXX_THROW_OR_ABORT(filesystem_error("cannot copy", from, to, ec));
}
We would need to reimplement the throwing form to do all the work, and throw at
the right places, or create a common implementation with an error context
object which either stores an error_code or throws when an error is reported.
[Bug fortran/120470] New: gfortran -Wexternal-argument-mismatch produces compile error on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120470 Bug ID: 120470 Summary: gfortran -Wexternal-argument-mismatch produces compile error on valid code Product: gcc Version: 15.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: albert at tugraz dot at Target Milestone: --- Created attachment 61545 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61545&action=edit Minimal reproducible example gcc version 15.1.1 20250425 (GCC) on Arch Linux $ gfortran -Wexternal-argument-mismatch -c issue.f90 fails with issue.f90:18:19: 18 | call inner(proc) | 1 Error: Interface mismatch in dummy procedure ‘proc’ at (1): Shape mismatch in argument 'x' The error is also triggered by `-Wall` and disappears when `-Wexternal-argument-mismatch` is not included in a set of flags. Expected behavior would be warnings only (if applicable), not an error. Version 14.2.1 20250207 that doesn't support `-Wexternal-argument-mismatch` works fine with `-Wall`, and throws only an "unused dummy argument" warning. $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/15.1.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust,cobol --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues --with-build-config=bootstrap-lto --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.1.1 20250425 (GCC)
[Bug c++/117785] [C++26] P3068R5 - constexpr exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
Jakub Jelinek changed:
What|Removed |Added
Attachment #61540|0 |1
is obsolete||
--- Comment #20 from Jakub Jelinek ---
Created attachment 61546
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61546&action=edit
gcc16-pr117785-wip.patch
Further progress.
My current problem is with std::nested_exception (but guess arbitrary code
which uses std::current_exception () or perhaps std::uncaught_exceptions ()).
In the testcase I have (simplified):
try
{
throw 42;
}
catch (...)
{
std::nested_exception c;
if (c.nested_ptr () == nullptr)
return -1;
}
and -1 is the return value I'm getting but don't expect.
The problem is that when parsing the c declaration, we try to constant evaluate
the constructor just in case it can be constructed without a call, and there
current_exception () returns { nullptr } because it isn't evaluated with an
active exception at that point.
Shall the two functions just give up when not manifestly constant-evaluated?
Or non-strict?
[Bug c++/107527] warning: declaration of ‘void operator delete(void*, std::size_t)’ has a different exception specifier [-Wsystem-headers]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107527 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |15.0 Resolution|--- |FIXED Last reconfirmed||2025-5-29 --- Comment #2 from Jonathan Wakely --- Fixed by r15-3532: c++: exception spec and stdlib specialization We were silently accepting the pr65923.C specialization of std::swap with the wrong exception specification; it should be declared noexcept. Let's limit ignoring mismatch with system headers to extern "C" functions so we get a diagnostic for the C++ library.
[Bug rtl-optimization/111901] Apparently bogus CSE of inline asm with memory clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #6 from Uroš Bizjak --- Created attachment 61544 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61544&action=edit Proposed patch Proposed patch avoids simplifications of ASMs that have memory clobber. The testcase now compiles for x86_64 to (-O2 -funroll-all-loops): test: magic %eax magic %edx addl%edx, %eax magic %ecx addl%ecx, %eax magic %esi addl%esi, %eax ret
[Bug c++/119864] [15/16 Regression][modules] ICE with -fmodules and omp reduction of UDT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119864 --- Comment #9 from Pilar Latiesa --- (In reply to Nathaniel Shead from comment #4) > The assertion is thrown when streaming the generated function "omp declare > reduction Op" because this is a DECL_LOCAL_DECL_P function but isn't on the > BLOCK of sum, so we didn't stream it by value when we were supposed to. Is the BLOCK incorrectly set or does it lack a DECL_CONTEXT at all? Thanks
[Bug c/120469] New: [SH] Delay slot optimization opportunity missed with atomic writes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120469
Bug ID: 120469
Summary: [SH] Delay slot optimization opportunity missed with
atomic writes
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: paul at crapouillou dot net
Target Milestone: ---
Given the following code:
#include
unsigned int val;
void reset_val(void) {
if (TEST_ATOMIC)
atomic_store(&val, 0);
else
val = 0;
}
When compiling with TEST_ATOMIC==0 for SH4 (-Os -fno-PIC -fomit-frame-pointer
-m4-single), the following code is generated:
_reset_val:
mov.l .L2,r1
mov #0,r2
rts
mov.l r2,@r1
.L2:
.long _val
_val:
.zero 4
When compiling with TEST_ATOMIC==1, the second mov.l does not fill the delay
slot:
_reset_val:
mov.l .L2,r1
mov #0,r2
mov.l r2,@r1
rts
nop
.L2:
.long _val
_val:
.zero 4
[Bug c++/120453] [16 regression] qcoro fails to build its tests (error: use of deleted function ... is implicitly deleted because the default definition would be ill-formed) since r16-773-ge06555a40c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120453
Iain Sandoe changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
||il/gcc-patches/2025-May/685
||037.html
--- Comment #14 from Iain Sandoe ---
patch posted.
Note that there is some implementation divergence in the handling of the
reduced test-case here. https://godbolt.org/z/3zrexzEas ( -DHAS_MOVE_CTOR to
add that back )
* clang-20 accepts the coroutine code.
* If we add the non-coroutine simulation of the ramp, then clang-20 also
complains - but with a different diagnostic:
":97:10: error: call to implicitly-deleted copy constructor of
'LazyTask'
97 | return Gro;
| ^~~
:84:41: note: copy constructor of 'LazyTask' is implicitly deleted
because base class 'detail::TaskBase' has a deleted copy
constructor
84 | template struct LazyTask : detail::TaskBase {
| ^
:51:8: note: copy constructor is implicitly deleted because
'TaskBase' has a user-declared move assignment
operator
51 | void operator=(TaskBase &&);
"
(rather than complaining about a default that would be ill-formed.)
[Bug libstdc++/99995] [12/13/14/15/16 Regression] should not include in c++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 Jonathan Wakely changed: What|Removed |Added Target Milestone|12.5|16.0
[Bug c++/120458] module-name does not allow non-ASCII characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120458 --- Comment #2 from Pilar Latiesa --- (In reply to Jonathan Wakely from comment #1) > Clang compiles this, and I think MSVC does, but EDG doesn't (but EDG also > doesn't accept that identifier for a variable name, at least with the > default options). I believe the necessary options are --c++20 --unicode_source_kind UTF-8
[Bug testsuite/120457] gcc.dg/vect/pr79920.c fail starting with r16-924-g1bc5b47f5b06dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120457
--- Comment #1 from Hongtao Liu ---
double __attribute__((noinline,noclone))
compute_integral (double w_1[18])
{
double A = 0;
double t33[2][6] = {{0.0, 0.0, 0.0, 0.0, 0.0, 0.0},
{0.0, 0.0, 0.0, 0.0, 0.0, 0.0}};
double t43[2] = {0.0, 0.0};
double t31[2][2] = {{1.0, 1.0}, {1.0, 1.0}};
double t32[2][3] = {{0.0, 0.0, 1.0}, {0.0, 0.0, 1.0}};
for (int ip_1 = 0; ip_1 < 2; ++ip_1)
{
#pragma GCC unroll 0
for (int i_0 = 0; i_0 < 6; ++i_0)
t33[ip_1][i_0] = ((w_1[i_0*3] * t32[ip_1][0])
+ (w_1[i_0*3+2] * t32[ip_1][2])); --- the loop is
not vectorized anymore for power
t43[ip_1] = 2.0;
}
for (int i_0 = 0; i_0 < 6; ++i_0)
A += t43[1]*t33[1][i_0];
return A;
}
[Bug testsuite/120457] gcc.dg/vect/pr79920.c fail starting with r16-924-g1bc5b47f5b06dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120457
--- Comment #2 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #1)
> double __attribute__((noinline,noclone))
> compute_integral (double w_1[18])
> {
> double A = 0;
> double t33[2][6] = {{0.0, 0.0, 0.0, 0.0, 0.0, 0.0},
> {0.0, 0.0, 0.0, 0.0, 0.0, 0.0}};
> double t43[2] = {0.0, 0.0};
> double t31[2][2] = {{1.0, 1.0}, {1.0, 1.0}};
> double t32[2][3] = {{0.0, 0.0, 1.0}, {0.0, 0.0, 1.0}};
>
> for (int ip_1 = 0; ip_1 < 2; ++ip_1)
> {
> #pragma GCC unroll 0
> for (int i_0 = 0; i_0 < 6; ++i_0)
> t33[ip_1][i_0] = ((w_1[i_0*3] * t32[ip_1][0])
> + (w_1[i_0*3+2] * t32[ip_1][2])); --- the loop is
> not vectorized anymore for power
W/o -fno-vect-cost-model, power doesn't vectorize the loop, because it's
suboptimal.
[Bug c++/120458] module-name does not allow non-ASCII characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120458 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2025-05-29 --- Comment #3 from Jonathan Wakely --- Ah yes, thanks! EDG accepts the code too.
[Bug bootstrap/120464] [16 Regression] Build broken in ggc-page.cc on master since r16-852
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120464 --- Comment #7 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:dc887145c0e9ae44e939dab3e0198346fe660793 commit r16-950-gdc887145c0e9ae44e939dab3e0198346fe660793 Author: Jakub Jelinek Date: Thu May 29 09:58:30 2025 +0200 ggc-page: Fix up build on non-USING_MMAP hosts [PR120464] The r16-852 "Use optimize free lists for alloc_pages" change broke build on non-USING_MMAP hosts. I don't have access to one, so I've just added #undef USING_MMAP before first use of that macro after the definitions. There were 2 problems. One was one missed G.free_pages to free_list->free_pages replacement in #ifdef USING_MALLOC_PAGE_GROUPS guarded code which resulted in obvious compile error. Once fixed, there was an ICE during self-test and without self-test pretty much on any garbage collection. The problem is that the patch moved all of release_pages into new do_release_pages and runs it for each freelist from the new release_pages wrapper. The #ifdef USING_MALLOC_PAGE_GROUPS code had two loops, one which walked the entries in the freelist and freed the ones which had unused group there and another which walked all the groups (regardless of which freelist they belong to) and freed the unused ones. With the change the first call to do_release_pages would free freelist entries from the first freelist with unused groups, then free all unused groups and then second and following would access already freed groups, crashing there, and then walk again all groups looking for unused ones (but there are guaranteed to be none). So, this patch fixes it by moving the unused group freeing to the caller, release_pages after all freelists are freed, and while at it, moves there the statistics printout as well, we don't need to print separate info for each of the freelist, previously we were emitting just one. 2025-05-29 Jakub Jelinek PR bootstrap/120464 * ggc-page.cc (struct ggc_globals): Fix up comment formatting. (find_free_list): Likewise. (alloc_page): For defined(USING_MALLOC_PAGE_GROUPS) use free_list->free_pages instead of G.free_pages. (do_release_pages): Add n1 and n2 arguments, make them used. Move defined(USING_MALLOC_PAGE_GROUPS) page group freeing to release_pages and dumping of statistics as well. Formatting fixes. (release_pages): Adjust do_release_pages caller, move here defined(USING_MALLOC_PAGE_GROUPS) page group freeing and dumping of statistics. (ggc_handle_finalizers): Fix up comment formatting and typo.
[Bug bootstrap/120464] [16 Regression] Build broken in ggc-page.cc on master since r16-852
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120464 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Should be fixed now.
[Bug middle-end/116815] Make better use of overflow flags in codegen of min/max(a, add/sub(a, b))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116815 Dhruv Chawla changed: What|Removed |Added CC||dhruvc at nvidia dot com --- Comment #4 from Dhruv Chawla --- Posted a patch to try and implement this: https://gcc.gnu.org/pipermail/gcc-patches/2025-May/685021.html
[Bug analyzer/120467] Analyzer: Diagnose cases where C++ 'std::basic_string_view::data()' is used as NUL-terminated string, but isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120467 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2025-05-29 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- I'm not sure how often this would be useful, it might be a pretty rare mistake, but it does seem useful to diagnose it for those rare cases.
