[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 119960, which changed state. Bug 119960 Summary: [15 Regression] vectorizer seems not to do as much any more since r15-5863 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119960 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/120182] Incorrect code with -O3 and constant addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120182 --- Comment #12 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:44792a6c4253f9a5b322797ef73b9c347c223545 commit r15-9785-g44792a6c4253f9a5b322797ef73b9c347c223545 Author: Richard Biener Date: Fri May 9 08:38:45 2025 +0200 rtl-optimization/120182 - wrong-code with RTL DSE and constant addresses RTL DSE forms store groups from unique invariant bases but that is confused when presented with constant addresses where it assigns one store group per unique address. That causes it to not consider 0x101:QI to alias 0x100:SI. Constant accesses can really alias to every object, in practice they appear for I/O and for access to objects fixed via linker scripts for example. So simply avoid registering a store group for them. PR rtl-optimization/120182 * dse.cc (canon_address): Constant addresses have no separate store group. * gcc.dg/torture/pr120182.c: New testcase. (cherry picked from commit b9434c3db900d5d037fdf2f64149b82800ceadf8)
[Bug tree-optimization/104178] [12 regression] -fcompare-debug failure at -O3 -m32 since r12-4790-g4b3a325f07acebf47e82de227ce1d5ba62f5bcae
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104178 Richard Biener changed: What|Removed |Added Known to fail||12.1.0 Last reconfirmed|2022-01-22 00:00:00 |2025-6-6 Known to work||11.5.0, 13.1.0 Priority|P1 |P2
[Bug libstdc++/118160] Dangling reference in std::ranges::is_permutation may cause a crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118160 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Jonathan Wakely --- Fixed for 13.5
[Bug cobol/119975] clock_gettime in genapi.cc is unportable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119975 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > commit r16-1193-g2e334900f4ddcd804e3b324402544a572d306ab6 > Author: Robert Dubner > Date: Thu Jun 5 10:53:02 2025 -0400 > > cobol: Guard clock_gettime(). [PR119975] > > This attempts to eliminate "'clock_gettime' not declared..." when > building on x86_64-apple-darwin15.6.0. Calls to clock_gettime have been > reduced to two locations. Both have been guarded with This patch allowed cobol1 to build on Darwin 15 now, thanks. However, libgcobol still doesn't build: In file included from /vol/gcc/src/hg/master/darwin/libgcobol/gfileio.cc:53: /vol/gcc/src/hg/master/darwin/libgcobol/libgcobol.h:115:17: error: variable or field '__gg__clock_gettime' declared void 115 | extern "C" void __gg__clock_gettime(clockid_t clk_id, struct cbl_timespec *tp); | ^~~ /vol/gcc/src/hg/master/darwin/libgcobol/libgcobol.h:115:37: error: 'clockid_t' was not declared in this scope; did you mean 'clock_t'? 115 | extern "C" void __gg__clock_gettime(clockid_t clk_id, struct cbl_timespec *tp); | ^ | clock_t There's no clockid_t without clock_gettime. Besides, there are several instances of /vol/gcc/src/hg/master/darwin/libgcobol/intrinsic.cc: In function 'void __gg__current_date(cblc_field_t*)': /vol/gcc/src/hg/master/darwin/libgcobol/intrinsic.cc:1222:23: error: 'CLOCK_REALTIME' was not declared in this scope 1222 | __gg__clock_gettime(CLOCK_REALTIME, &tp); // time_t tv_sec; long tv_nsec | ^~ which cannot work either. And there's also an unguarded call to clock_gettime in __gg__clock_gettime.
[Bug tree-optimization/113239] [13/14 regression] After r13-6372-g822a11a1e642e0, bogus -Warray-bounds warnings in std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113239
--- Comment #15 from Jonathan Wakely ---
This makes the compiler shut up:
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -605,6 +605,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
: _Base(__x.size(),
_Alloc_traits::_S_select_on_copy(__x._M_get_Tp_allocator()))
{
+ if (__x.size() > capacity())
+ __builtin_unreachable();
+
this->_M_impl._M_finish =
std::__uninitialized_copy_a(__x.begin(), __x.end(),
this->_M_impl._M_start,
[Bug modula2/120542] Return statement in the main procedure crashes the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120542 --- Comment #3 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:16ab791531ec16fd4596a25efbe6b42e6c16171f commit r16-1251-g16ab791531ec16fd4596a25efbe6b42e6c16171f Author: Gaius Mulley Date: Fri Jun 6 10:46:48 2025 +0100 PR modula2/120542: Return statement in the main procedure crashes the compiler The patch checks whether a return statement is allowed. It also checks to see that a return expression is allowed. gcc/m2/ChangeLog: PR modula2/120542 * gm2-compiler/M2Quads.mod (BuildReturnLower): New procedure. (BuildReturn): Allow return without an expression from module initialization blocks. Generate an error if an expression is provided. Call BuildReturnLower if no error was seen. gcc/testsuite/ChangeLog: PR modula2/120542 * gm2/iso/fail/badreturn.mod: New test. * gm2/iso/fail/badreturn2.mod: New test. * gm2/iso/pass/modulereturn.mod: New test. * gm2/iso/pass/modulereturn2.mod: New test. Signed-off-by: Gaius Mulley
[Bug libstdc++/120567] New: [16 Regression] std::stacktrace tests now fail on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120567
Bug ID: 120567
Summary: [16 Regression] std::stacktrace tests now fail on
arm-eabi
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: testsuite-fail
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
Target: arm-eabi
My changes for Bug 119667 cause test failures on arm-eabi:
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/arm-eabi/bin/ld:
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/src/experimental/.libs/libstdc++exp.a(std_stacktrace-fileline.o):
in function `fileline_initialize':
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/src/libbacktrace/fileline.c:260:(.text+0x74):
warning: This implementation of __sync_synchronize is a stub with no effect.
Relink with
-specs=sync-{none,dmb,cp15dmb}.specs
to specify exactly which barrier format to use and avoid this warning
The problem is that the new configure tests for atomics needed by libbacktrace
do this:
int i = 0;
int* p = &i;
__SIZE_TYPE__ s = 0;
// backtrace_atomic_load_pointer
void* vp = __atomic_load_n(&p, __ATOMIC_ACQUIRE);
// backtrace_atomic_load_int
int i2 = __atomic_load_n(&i, __ATOMIC_ACQUIRE);
// backtrace_atomic_store_pointer
__atomic_store_n(&p, &i, __ATOMIC_RELEASE);
// backtrace_atomic_store_size_t
__atomic_store_n(&s, s, __ATOMIC_RELEASE);
// backtrace_atomic_store_int
__atomic_store_n(&i, i, __ATOMIC_RELEASE);
and this does compile, and doesn't emit any references to __atomic_load_n or
__atomic_store_n, but it does emit references to __sync_synchronize:
mov r3, #0
str r3, [fp, #-24]
sub r3, fp, #24
str r3, [fp, #-28]
mov r3, #0
str r3, [fp, #-32]
sub r3, fp, #28
ldr r4, [r3]
bl __sync_synchronize
str r4, [fp, #-16]
sub r3, fp, #24
ldr r4, [r3]
bl __sync_synchronize
str r4, [fp, #-20]
sub r5, fp, #24
sub r4, fp, #28
bl __sync_synchronize
str r5, [r4]
ldr r5, [fp, #-32]
sub r4, fp, #32
bl __sync_synchronize
str r5, [r4]
ldr r3, [fp, #-24]
mov r5, r3
sub r4, fp, #24
bl __sync_synchronize
str r5, [r4]
I'm not sure whether we want to avoid using atomics for stacktraces on
arm-eabi, or require one of those specs options for the testsuite.
[Bug target/120515] darwin warning: ld: warning: -U option is redundant when using -undefined dynamic_lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120515 --- Comment #2 from Peter Eisentraut --- Yes, I did figure that out, and -nodefaultexport does work. But as you said, it's not documented, and it's not clear whether it should be the burden of the user to use it.
[Bug c/120566] Possible memory leak in set_multilib_dir at gcc.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120566 Richard Biener changed: What|Removed |Added Keywords||internal-improvement Status|UNCONFIRMED |NEW Last reconfirmed||2025-06-06 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Note 'gcc' is a short-lived program and it's overall allocations are small so we do not consider such leaks important to fix if doing so would impact code readability a lot.
[Bug libstdc++/120565] Outputing sys_info, local_info as wchar_t is ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120565
--- Comment #1 from GCC Commits ---
The master branch has been updated by Tomasz Kaminski :
https://gcc.gnu.org/g:6dcba678030181527c6010551387917b8d734904
commit r16-1205-g6dcba678030181527c6010551387917b8d734904
Author: Tomasz KamiÅski
Date: Fri Jun 6 09:07:49 2025 +0200
libstdc++: Support wide characters output for sys_info and local_info
[PR120565]
Formatting sys_info as wchar_t require widening of the abbrev (zone)
member.
To support that we reuse the existing code in support for '%Z' specifier,
for
local_time_format, and produce output using singe format call with
"[{0:%F %T},{1:%F %T},{2:%T},{3:%Q%q},{0:%Z}]" format string. As noted in
the
comment, produced output is locale independed, as it does not contain
decimal
separtors.
For sys_info, the outputed literals are widended using _GLIBCXX_WIDEN,
except
opening and closing brackets, that are fetched from __format::_Separators.
PR libstdc++/120565
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h
(operator<<(basic_ostream<_CharT, _Traits>&, const sys_info&))
(operator<<(basic_ostream<_CharT, _Traits>&, const local_info&)):
Support wchar_t as _CharT.
* testsuite/std/time/format/empty_spec.cc: Instantiated test_infos
for
wchar_t and increase timeout.
Reviewed-by: Jonathan Wakely
Signed-off-by: Tomasz KamiÅski
[Bug libstdc++/100249] missing forwarding std::__invoke result in ranges::is_permutation and ranges::clamp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100249 --- Comment #19 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:63be00fe4cad2552edcda863087adcce0b2aa236 commit r13-9745-g63be00fe4cad2552edcda863087adcce0b2aa236 Author: Giuseppe D'Angelo Date: Thu Feb 6 14:24:17 2025 + libstdc++: fix a dangling reference crash in ranges::is_permutation [PR118160] The code was caching the result of `invoke(proj, *it)` in a local `auto &&` variable. The problem is that this may create dangling references, for instance in case `proj` is `std::identity` (the common case) and `*it` produces a prvalue: lifetime extension does not apply here due to the expressions involved. Instead, store (and lifetime-extend) the result of `*it` in a separate variable, then project that variable. While at it, also forward the result of the projection to the predicate, so that the predicate can act on the proper value category. libstdc++-v3/ChangeLog: PR libstdc++/118160 PR libstdc++/100249 * include/bits/ranges_algo.h (__is_permutation_fn): Avoid a dangling reference by storing the result of the iterator dereference and the result of the projection in two distinct variables, in order to lifetime-extend each one. Forward the projected value to the predicate. * testsuite/25_algorithms/is_permutation/constrained.cc: Add a test with a range returning prvalues. Test it in a constexpr context, in order to rely on the compiler to catch UB. Signed-off-by: Giuseppe D'Angelo (cherry picked from commit 2a2bd96d0d2109384a0eedde843ba811d2e18738)
[Bug tree-optimization/119960] [15 Regression] vectorizer seems not to do as much any more since r15-5863
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119960 --- Comment #13 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:8fb3d9066266ea30de62c395239bda4e992297a3 commit r15-9782-g8fb3d9066266ea30de62c395239bda4e992297a3 Author: Richard Biener Date: Tue Apr 29 13:23:41 2025 +0200 tree-optimization/119960 - failed external SLP promotion The following addresses a too conservative sanity check of SLP nodes we want to promote external. The issue lies in code generation for such external which relies on get_later_stmt to figure an insert location. But get_later_stmt relies on the ability to totally order stmts, specifically implementation-wise that they are all from the same BB, which is what is verified at the moment. The patch changes this to require stmts to be orderable by dominance queries. For simplicity and seemingly enough for the testcase in PR119960, this handles the case of two distinct BBs. PR tree-optimization/119960 * tree-vect-slp.cc (vect_slp_can_convert_to_external): Handle cases where defs from multiple BBs are ordered by their dominance relation. * gcc.dg/vect/bb-slp-pr119960-1.c: New testcase. (cherry picked from commit cc74e2f2b39b6debbef1787a087abad2108e95dd)
[Bug tree-optimization/120003] [12/13/14/15 Regression] missed optimization around a loop with a checker since r12-3453-g01b5038718056b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120003 --- Comment #11 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:4d375ebd56c54dc8c242bed988f29094b7e3e94e commit r15-9783-g4d375ebd56c54dc8c242bed988f29094b7e3e94e Author: Richard Biener Date: Wed Apr 30 11:52:17 2025 +0200 tree-optimization/120003 - missed jump threading The following allows the entry and exit block of a jump thread path to be equal, which can easily happen when there isn't a forwarder on the interesting edge for an FSM thread conditional. We just don't want to enlarge the path from such a block. PR tree-optimization/120003 * tree-ssa-threadbackward.cc (back_threader::find_paths_to_names): Allow block re-use but do not enlarge the path beyond such a re-use. * gcc.dg/tree-ssa/ssa-thread-23.c: New testcase. * gcc.dg/tree-ssa/ssa-dom-thread-7.c: Adjust. (cherry picked from commit 1a13684dfc7286139064f7d7341462c9995cbd1c)
[Bug libstdc++/118160] Dangling reference in std::ranges::is_permutation may cause a crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118160 --- Comment #7 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:63be00fe4cad2552edcda863087adcce0b2aa236 commit r13-9745-g63be00fe4cad2552edcda863087adcce0b2aa236 Author: Giuseppe D'Angelo Date: Thu Feb 6 14:24:17 2025 + libstdc++: fix a dangling reference crash in ranges::is_permutation [PR118160] The code was caching the result of `invoke(proj, *it)` in a local `auto &&` variable. The problem is that this may create dangling references, for instance in case `proj` is `std::identity` (the common case) and `*it` produces a prvalue: lifetime extension does not apply here due to the expressions involved. Instead, store (and lifetime-extend) the result of `*it` in a separate variable, then project that variable. While at it, also forward the result of the projection to the predicate, so that the predicate can act on the proper value category. libstdc++-v3/ChangeLog: PR libstdc++/118160 PR libstdc++/100249 * include/bits/ranges_algo.h (__is_permutation_fn): Avoid a dangling reference by storing the result of the iterator dereference and the result of the projection in two distinct variables, in order to lifetime-extend each one. Forward the projected value to the predicate. * testsuite/25_algorithms/is_permutation/constrained.cc: Add a test with a range returning prvalues. Test it in a constexpr context, in order to rely on the compiler to catch UB. Signed-off-by: Giuseppe D'Angelo (cherry picked from commit 2a2bd96d0d2109384a0eedde843ba811d2e18738)
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2025-06-06 Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #13 from Paul Thomas --- Created attachment 61595 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61595&action=edit Patch in development for this PR The attached regtests OK. There are two wrinkles noted in the testcase. The error detected by ifx was supposed to be identified by the first chunk in decl.cc so I will have to delve further. I have yet to find the corresponding constraint in the standard. Comments/suggestions are welcome. Paul
[Bug tree-optimization/120523] gcc.dg/tree-ssa/cswtch-6.c fails on aarch64 (and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120523 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #2 from Rainer Orth --- The test also FAILs on 32-bit x86 (both Solaris and Linux): .section.rodata compared to the 64-bit x86 .section.rodata.cst16,"aM",@progbits,16 Also, on SPARC (32 and 64-bit) there's .section".rodata"
[Bug c++/120555] [15/16 Regression] Use of auto func before deduction of auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120555 --- Comment #3 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8d204f2a536f7253e4251aca7bc12af524800b4c commit r16-1272-g8d204f2a536f7253e4251aca7bc12af524800b4c Author: Jason Merrill Date: Fri Jun 6 10:26:28 2025 -0400 c++: recursive template with deduced return [PR120555] Here since r15-4120 we were prematurely complaining about the use of func within its own definiton, which is fine at instantiation time. So don't require this for function templates that are currently being defined. But keep the error for instantiations of templates that are not currently being defined, which we similarly did not diagnose before r15-4120 but other implementations do. Both of these follow the general principle from [temp.res.general]/6 that we only error in a template body if no instatiation could be well-formed. Also remove a redundant call to require_deduced_type. PR c++/120555 gcc/cp/ChangeLog: * decl2.cc (fn_being_defined, fn_template_being_defined): New. (mark_used): Check fn_template_being_defined. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/constexpr-if39.C: New test.
[Bug cobol/120554] libgcobol meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120554 James K. Lowden changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot gnu.org Ever confirmed|0 |1 CC||jklowden at gcc dot gnu.org Last reconfirmed||2025-06-06 Status|UNCONFIRMED |ASSIGNED
[Bug cobol/119896] Assertion failed: e->type == SymField, function cbl_field_of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119896 --- Comment #3 from James K. Lowden --- We are waiting for cfarm access to appropriate machines, to reproduce. If you are so inclined, feel free to post a gdb backtrace for one of the assertions. Perhaps the old stare-at-the-code trick will expose something. The fact that occurs on Solaris/amd64 contradicts my endian instinct. Since we test on x86_64 all the time, but on Ubuntu, perhaps we're tripping on Solaris standard library behavior.
[Bug cobol/119695] Incorrect diagnostic format specifiers in COBOL FE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119695 --- Comment #5 from GCC Commits --- The master branch has been updated by Robert Dubner : https://gcc.gnu.org/g:37f5fdd008399c239e0689f2e864519505c78c7e commit r16-1273-g37f5fdd008399c239e0689f2e864519505c78c7e Author: Robert Dubner Date: Fri Jun 6 16:32:22 2025 -0400 cobol: Diagnostic messages, Flex build, and some cppcheck reports. [PR120328, PR119695] Remove %0x and similar from diagnostic framework messages. Remove %zu from printf messages because it is not supported on some platforms. Corrections in response to cppcheck. Sundry small fixes. gcc/cobol/ChangeLog: PR cobol/120328 * Make-lang.in: Success with non-English locale. PR cobol/119695 * cbldiag.h (cbl_unimplemented_at): Comment: * cdf-copy.cc (copybook_elem_t::open_file): Indentation. * cdf.y: YYABORT on certain errors. * cdfval.h (cdf_value): Const parameter. * copybook.h (class copybook_elem_t): Initialization. (class uppername_t): Explicit constructor. * except.cc (ec_type_descr): Remove %04s. (cbl_enabled_exceptions_t::dump): Remove %zu. * exceptg.h (class exception_turn_t): Explicit constructor. * genapi.cc (parser_perform_conditional): Remove %zu. (set_exception_environment): Formatting. (parser_statement_begin): Exception overhead. (parser_perform_conditional): Formatting: (parser_perform_conditional_end): Eliminate size_t. (parser_check_fatal_exception): Exception overhead. (parser_perform_conditional_end): Remove %zu. * inspect.h (struct cbx_inspect_match_t): Const reference. (struct cbx_inspect_t): Const parameter. * lexio.cc (cdftext::process_file): Remove %zu. * lexio.h (struct YYLTYPE): Remove unneeded struct. (YYLTYPE_IS_DECLARED): Likewise. (YYLTYPE_IS_TRIVIAL): Likewise. * parse.y: Comment; change DOT. * scan.l: Scan function names without swallowing whitespace. * scan_ante.h (scanner_parsing): Remove %zu. (scanner_parsing_pop): Remove %zu. (binary_integer_usage): Remove %zu. * scan_post.h (prelex): Correct post-CDF resumption. (yylex): Clearer message. * symbols.cc (symbol_table_extend): Explicit constructor. (elementize): Const parameter. (is_variable_length): Correct always-false. (symbols_update): Remove unnecessary shadow variable. (struct symbol_elem_t): Const parameter. (symbol_alphabet_add): Const parameter. (new_literal_add): Initialization. * symbols.h (class cbl_domain_elem_t): Correct assignment. (struct cbl_span_t): Improve constructor. (struct cbl_refer_t): Initialization. (struct cbl_alphabet_t): Rename shadow variable. (struct cbl_file_key_t): Remove unused constructor. (struct symbol_elem_t): Initialization. (struct cbl_until_addresses_t): Use unsigned int, for messages. (struct cbl_prog_hier_t): Initialization. (struct cbl_perform_tgt_t): Repair constructor. (struct cbl_label_t): Const parameter. (symbol_typedef_add): Const parameter. (symbol_field_add): Explicit constructor. (symbol_label_add): Explicit constructor. (symbol_program_add): Remove C-style "struct" use. (symbol_special_add): Remove C-style "struct" use. (symbol_alphabet_add): Const parameter. (symbol_file_add): Remove C-style "struct" use. (symbol_section_add): Remove C-style "struct" use. * symfind.cc: Const parameter. * util.cc (gb4): New function. * util.h (gb4): New function. * TODO: New file. libgcobol/ChangeLog: * common-defs.h (enum cbl_file_mode_t): Whitespace. (enum file_stmt_t): Likewise. (ec_cmp): Likewise. (struct cbl_declarative_t): Add "explicit" keyword. (class cbl_enabled_exceptions_t): Whitespace. * gfileio.cc: Remove cppcheck comment. * libgcobol.cc (class ec_status_t): Add "explicit" keyword. (match_declarative): Remove %zu. (default_exception_handler): Likwise. (__gg__check_fatal_exception): Exception overhead. (__gg__exception_push): Remove %zu. (__gg__exception_pop): Likewise. (cbl_enabled_exception_t::dump): Likewise. (__gg__match_exception): Exception overhead; remove %zu. (cbl_enabled_exceptions_t::dump): Remove %zu. (__gg__set_exception_environment): Likewise. Co-authored-by: James K. Lowden Co-authored-by: Robert Dub
[Bug cobol/120328] Building gcobol fails in non English systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120328 --- Comment #3 from GCC Commits --- The master branch has been updated by Robert Dubner : https://gcc.gnu.org/g:37f5fdd008399c239e0689f2e864519505c78c7e commit r16-1273-g37f5fdd008399c239e0689f2e864519505c78c7e Author: Robert Dubner Date: Fri Jun 6 16:32:22 2025 -0400 cobol: Diagnostic messages, Flex build, and some cppcheck reports. [PR120328, PR119695] Remove %0x and similar from diagnostic framework messages. Remove %zu from printf messages because it is not supported on some platforms. Corrections in response to cppcheck. Sundry small fixes. gcc/cobol/ChangeLog: PR cobol/120328 * Make-lang.in: Success with non-English locale. PR cobol/119695 * cbldiag.h (cbl_unimplemented_at): Comment: * cdf-copy.cc (copybook_elem_t::open_file): Indentation. * cdf.y: YYABORT on certain errors. * cdfval.h (cdf_value): Const parameter. * copybook.h (class copybook_elem_t): Initialization. (class uppername_t): Explicit constructor. * except.cc (ec_type_descr): Remove %04s. (cbl_enabled_exceptions_t::dump): Remove %zu. * exceptg.h (class exception_turn_t): Explicit constructor. * genapi.cc (parser_perform_conditional): Remove %zu. (set_exception_environment): Formatting. (parser_statement_begin): Exception overhead. (parser_perform_conditional): Formatting: (parser_perform_conditional_end): Eliminate size_t. (parser_check_fatal_exception): Exception overhead. (parser_perform_conditional_end): Remove %zu. * inspect.h (struct cbx_inspect_match_t): Const reference. (struct cbx_inspect_t): Const parameter. * lexio.cc (cdftext::process_file): Remove %zu. * lexio.h (struct YYLTYPE): Remove unneeded struct. (YYLTYPE_IS_DECLARED): Likewise. (YYLTYPE_IS_TRIVIAL): Likewise. * parse.y: Comment; change DOT. * scan.l: Scan function names without swallowing whitespace. * scan_ante.h (scanner_parsing): Remove %zu. (scanner_parsing_pop): Remove %zu. (binary_integer_usage): Remove %zu. * scan_post.h (prelex): Correct post-CDF resumption. (yylex): Clearer message. * symbols.cc (symbol_table_extend): Explicit constructor. (elementize): Const parameter. (is_variable_length): Correct always-false. (symbols_update): Remove unnecessary shadow variable. (struct symbol_elem_t): Const parameter. (symbol_alphabet_add): Const parameter. (new_literal_add): Initialization. * symbols.h (class cbl_domain_elem_t): Correct assignment. (struct cbl_span_t): Improve constructor. (struct cbl_refer_t): Initialization. (struct cbl_alphabet_t): Rename shadow variable. (struct cbl_file_key_t): Remove unused constructor. (struct symbol_elem_t): Initialization. (struct cbl_until_addresses_t): Use unsigned int, for messages. (struct cbl_prog_hier_t): Initialization. (struct cbl_perform_tgt_t): Repair constructor. (struct cbl_label_t): Const parameter. (symbol_typedef_add): Const parameter. (symbol_field_add): Explicit constructor. (symbol_label_add): Explicit constructor. (symbol_program_add): Remove C-style "struct" use. (symbol_special_add): Remove C-style "struct" use. (symbol_alphabet_add): Const parameter. (symbol_file_add): Remove C-style "struct" use. (symbol_section_add): Remove C-style "struct" use. * symfind.cc: Const parameter. * util.cc (gb4): New function. * util.h (gb4): New function. * TODO: New file. libgcobol/ChangeLog: * common-defs.h (enum cbl_file_mode_t): Whitespace. (enum file_stmt_t): Likewise. (ec_cmp): Likewise. (struct cbl_declarative_t): Add "explicit" keyword. (class cbl_enabled_exceptions_t): Whitespace. * gfileio.cc: Remove cppcheck comment. * libgcobol.cc (class ec_status_t): Add "explicit" keyword. (match_declarative): Remove %zu. (default_exception_handler): Likwise. (__gg__check_fatal_exception): Exception overhead. (__gg__exception_push): Remove %zu. (__gg__exception_pop): Likewise. (cbl_enabled_exception_t::dump): Likewise. (__gg__match_exception): Exception overhead; remove %zu. (cbl_enabled_exceptions_t::dump): Remove %zu. (__gg__set_exception_environment): Likewise. Co-authored-by: James K. Lowden Co-authored-by: Robert Dub
[Bug cobol/119896] Assertion failed: e->type == SymField, function cbl_field_of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119896 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from James K. Lowden --- > We are waiting for cfarm access to appropriate machines, to reproduce. Good. I just saw that Robert's account is already set up. > If you are so inclined, feel free to post a gdb backtrace for one of the > assertions. Perhaps the old stare-at-the-code trick will expose something. Sure. This is for Assertion failed: e->type == SymLabel, file /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h, line 1824, function cbl_label_of when compiling cobol1 cobol.dg/group2/ALLOCATE_Rule_8_OPTION_INITIALIZE_with_figconst.cob -quiet -main=cobol.dg/group2/ALLOCATE_Rule_8_OPTION_INITIALIZE_with_figconst.cob -m64 -mtune=generic -march=x86-64 -O0 #0 0xfdf2f525 in abort () from /lib/libc.so.1 #1 0xfdf307e0 in _assert_c99 () from /lib/libc.so.1 #2 0x096abc1f in cbl_label_of (e=) at /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h:1824 #3 0x096b5727 in cbl_label_of (e=) at /vol/gcc/src/hg/master/local/gcc/cobol/parse_ante.h:2386 #4 current_t::program (this=0xbdb1240 ) at /vol/gcc/src/hg/master/local/gcc/cobol/parse_ante.h:2108 #5 current_program_index () at /vol/gcc/src/hg/master/local/gcc/cobol/parse_ante.h:2385 #6 0x096fbb80 in typed_name (name=0xbfc1aba "based-p") at /vol/gcc/src/hg/master/local/gcc/cobol/scan_ante.h:712 #7 0x0970386d in lexer () at /vol/gcc/src/hg/master/local/gcc/cobol/scan.l:1129 #8 0x09722b3d in next_token () at /vol/gcc/src/hg/master/local/gcc/cobol/scan_post.h:240 #9 prelex () at /vol/gcc/src/hg/master/local/gcc/cobol/scan_post.h:251 #10 0x097230b0 in yylex () at /vol/gcc/src/hg/master/local/gcc/cobol/scan_post.h:375 #11 0x096c8393 in yyparse () at cobol/parse.cc:16483 #12 0x09748bed in parse_file ( filename=0xfeffde03 "/vol/gcc/src/hg/master/local/gcc/testsuite/cobol.dg/group2/ALLOCATE_Rule_8_OPTION_INITIALIZE_with_figconst.cob") at /vol/gcc/src/hg/master/local/gcc/cobol/util.cc:2183 #13 cobol_parse_files (nfile=1, files=0xbf99948) at /vol/gcc/src/hg/master/local/gcc/cobol/util.cc:2247 #14 0x0963ecc7 in cobol_langhook_parse_file () at /vol/gcc/src/hg/master/local/gcc/cobol/cobol1.cc:455 #15 0x09e01b0c in compile_file () at /vol/gcc/src/hg/master/local/gcc/toplev.cc:451 #16 0x09e051c0 in do_compile () at /vol/gcc/src/hg/master/local/gcc/toplev.cc:2207 #17 toplev::main (this=, argc=, argv=) at /vol/gcc/src/hg/master/local/gcc/toplev.cc:2370 #18 0x0b3aad71 in main (argc=8, argv=0xfeffdc54) at /vol/gcc/src/hg/master/local/gcc/main.cc:39 I can rebuild cobol1 with -g3 -O0 to get more useful information.
[Bug target/102294] memset expansion is sometimes slow for small sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102294 --- Comment #29 from H.J. Lu --- (In reply to Mateusz Guzik from comment #28) > (In reply to H.J. Lu from comment #27) > > (In reply to Mateusz Guzik from comment #26) > > > 4 stores per loop is best > > > > Do you have data to show it? > > I used to, but I'm out of this game. > > However, this is what gcc is already emitting if you explicitly ask it for > unrolled loops, so I don't think this bit should be controversial. It is hard to believ 8 stores slower than a loop.
[Bug target/102294] memset expansion is sometimes slow for small sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102294 --- Comment #30 from Mateusz Guzik --- (In reply to H.J. Lu from comment #29) > (In reply to Mateusz Guzik from comment #28) > > (In reply to H.J. Lu from comment #27) > > > (In reply to Mateusz Guzik from comment #26) > > > > 4 stores per loop is best > > > > > > Do you have data to show it? > > > > I used to, but I'm out of this game. > > > > However, this is what gcc is already emitting if you explicitly ask it for > > unrolled loops, so I don't think this bit should be controversial. > > It is hard to believ 8 stores slower than a loop. I once more point out I'm discussing the case of *no* simd usage. With the example of 128 bytes I provided, that would be 16 stores. I also claim punting to libcall is ok past 256 bytes, with regular stores otherwise (no rep prefix). For 256 in particular that's 32 mov instructions. At some point this is an i-cache footprint tradeoff. Stock gcc already decides to do 4 stores loops if asked to refrain from using rep mov/stos, so I don't see why anybody would protest sticking to that specific size.
[Bug middle-end/110459] Trivial on stack variable was not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110459 Andrew Pinski changed: What|Removed |Added Attachment #61589|0 |1 is obsolete|| --- Comment #7 from Andrew Pinski --- Created attachment 61597 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61597&action=edit New patch based on the review This version is in testing but it works and maybe it is better than before.
[Bug tree-optimization/120533] GCN: FAIL: gcc.dg/tree-ssa/phiprop-2.c scan-tree-dump-times phiopt2 "MIN_EXPR " 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120533 --- Comment #4 from Andrew Pinski --- I have a patch to fix this in testing; should be able to post it this evening.
[Bug cobol/119633] compile error for debug-module USE FOR DEBUGGING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119633 James K. Lowden changed: What|Removed |Added Status|ASSIGNED|SUSPENDED Severity|normal |enhancement --- Comment #3 from James K. Lowden --- > USE FOR DEBUGGING ON ALL REFERENCES OF FREC I can find no compiler that supports that syntax. IMO the error message is fine. The parser doesn't recognize REFERENCES as a keyword, assumes it's a user-defined NAME (a data-item) that was not defined, and indicates a syntax error. Perhaps, if and when we decide to support the NIST DB module, we could implement a specific message at that time, or support the DB303M syntax. > DB303M.CBL:33:8: error: missing END DECLARATIVES or SECTION name This is unfortunate, but harder to fix than one might hope. Because of the grammar, if the first USE statement in DECLARATIVES has a syntax error, Bison recovery invalidates the entire Procedure Division. Experimenting with custom anticipation of the erroneous syntax didn't lead to significantly better results. I'm setting this PR for this particular problem to suspended, as a feature request.
[Bug tree-optimization/120533] GCN: FAIL: gcc.dg/tree-ssa/phiprop-2.c scan-tree-dump-times phiopt2 "MIN_EXPR " 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120533 --- Comment #5 from Andrew Pinski --- Cleanup first: https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686046.html The actual patch: https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686047.html
[Bug middle-end/110459] Trivial on stack variable was not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110459 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > Created attachment 61597 [details] > New patch based on the review > > This version is in testing but it works and maybe it is better than before. Causes an ICE while building libstdc++. trying to reduce it and seeing what can be done about it.
[Bug target/120550] [16 Regression] RISC-V: Miscompile at -O3 since r16-372-g064cac730f8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120550 Jeffrey A. Law changed: What|Removed |Added Last reconfirmed||2025-06-06 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug target/102294] memset expansion is sometimes slow for small sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102294 --- Comment #31 from H.J. Lu --- (In reply to Mateusz Guzik from comment #30) > (In reply to H.J. Lu from comment #29) > > (In reply to Mateusz Guzik from comment #28) > > > (In reply to H.J. Lu from comment #27) > > > > (In reply to Mateusz Guzik from comment #26) > > > > > 4 stores per loop is best > > > > > > > > Do you have data to show it? > > > > > > I used to, but I'm out of this game. > > > > > > However, this is what gcc is already emitting if you explicitly ask it for > > > unrolled loops, so I don't think this bit should be controversial. > > > > It is hard to believ 8 stores slower than a loop. > > I once more point out I'm discussing the case of *no* simd usage. > > With the example of 128 bytes I provided, that would be 16 stores. > > I also claim punting to libcall is ok past 256 bytes, with regular stores > otherwise (no rep prefix). For 256 in particular that's 32 mov instructions. > > At some point this is an i-cache footprint tradeoff. > > Stock gcc already decides to do 4 stores loops if asked to refrain from > using rep mov/stos, so I don't see why anybody would protest sticking to > that specific size. Please describe your suggestions in "stores", not "bytes".
[Bug target/120550] [16 Regression] RISC-V: Miscompile at -O3 since r16-372-g064cac730f8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120550 --- Comment #3 from Jeffrey A. Law --- I suspect the bisection landing on the inliner heuristic change is a bit of a red herring. Forcing that first function to be static inline and I can see this well back in the gcc15 cycle.
[Bug target/120550] [16 Regression] RISC-V: Miscompile at -O3 since r16-372-g064cac730f8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120550 Jeffrey A. Law changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Jeffrey A. Law --- Landed on the initial introduction of ext-dce. Which makes sense if you look at the two values. -10 and 246 :-) Anyway, mine.
[Bug middle-end/110459] Trivial on stack variable was not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110459
Andrew Pinski changed:
What|Removed |Added
Attachment #61597|0 |1
is obsolete||
--- Comment #9 from Andrew Pinski ---
Created attachment 61598
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61598&action=edit
includes the fix for libstdc++
Simplified C testcase for the ICE:
```
struct a {
int b;
int c;
int d;
} e;
void f() {
e = (struct a){};
}
```
Basically if we have a target, then using 0 is wrong, we should continue on to
the store_constructor part.
[Bug c++/113754] GCC complains when using a type that depends on lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113754 Stas Sergeev changed: What|Removed |Added CC||stsp at users dot sourceforge.net --- Comment #3 from Stas Sergeev --- I have the same problem, but without using decltype: https://godbolt.org/z/fxa95eKvh It seems to happen on gcc-14, but probably not on 15. Is this a different problem?
[Bug target/120550] [16 Regression] RISC-V: Miscompile at -O3 since r16-372-g064cac730f8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120550 --- Comment #5 from Jeffrey A. Law --- Initial analysis is that ext-dce is fine at least as far as the RTL is concerned. Will need to look at combine next.
[Bug target/102294] memset expansion is sometimes slow for small sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102294 --- Comment #32 from Mateusz Guzik --- For non-simd asm you can do at most 8 bytes per one mov instruction. Stock gcc resorts to rep movsq for sizes bigger than 40 bytes. Telling it to not use rep movsq results in loops of 4 movsq instructions (aka 32 bytes per iteration). An ok upper limit to still do this instead of punting to libcall is 256 bytes. In case of -mno-simd I'm advocating for issuing the 32-byte (aka 4 store) loops up to 256 bytes and punting to libcall otherwise. Fully unrolling these would raise numerous eyebrows due to i-cache footprint and I don't believe this is warranted.
[Bug target/102294] memset expansion is sometimes slow for small sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102294 --- Comment #33 from H.J. Lu --- (In reply to Mateusz Guzik from comment #32) > For non-simd asm you can do at most 8 bytes per one mov instruction. > > Stock gcc resorts to rep movsq for sizes bigger than 40 bytes. Telling it to > not use rep movsq results in loops of 4 movsq instructions (aka 32 bytes per > iteration). > > An ok upper limit to still do this instead of punting to libcall is 256 > bytes. > > In case of -mno-simd I'm advocating for issuing the 32-byte (aka 4 store) > loops up to 256 bytes and punting to libcall otherwise. > > Fully unrolling these would raise numerous eyebrows due to i-cache footprint > and I don't believe this is warranted. One store can move up to 64 bytes.
[Bug target/102294] memset expansion is sometimes slow for small sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102294 --- Comment #34 from H.J. Lu --- Please describe your suggestions in stores, not bytes. Please don't use numbers like 256 bytes.
[Bug target/120513] Possible arch or configure issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #23 from Greg Chandler ---
Well, it was a no-go, so I rebuilt again with --enable-checking=all
root@bigbang:/tmp# cat /tmp/1.c
#include
#include
int main ()
{
}
root@bigbang:/tmp# gcc /tmp/1.c -wrapper gdb
GNU gdb (GDB) 16.3
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "alpha-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
[Bug target/120513] Possible arch or configure issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #24 from Greg Chandler ---
I took another look at the strack trace, comparing it to the cross-compiler on
the build system.
Build system:
newfstatat(AT_FDCWD,
"/opt/tools/bin/../lib/gcc/alpha-linux-gnu/14.2.0/include",
{st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
newfstatat(AT_FDCWD,
"/opt/tools/bin/../lib/gcc/alpha-linux-gnu/14.2.0/include-fixed",
{st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
newfstatat(AT_FDCWD,
"/opt/tools/bin/../lib/gcc/alpha-linux-gnu/14.2.0/../../../../alpha-linux-gnu/include",
{st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
newfstatat(AT_FDCWD,
"/opt/tools/bin/../lib/gcc/../../lib/gcc/alpha-linux-gnu/14.2.0/include",
{st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
newfstatat(AT_FDCWD, "/opt/usr/local/include", {st_mode=S_IFDIR|0755,
st_size=4096, ...}, 0) = 0
newfstatat(AT_FDCWD,
"/opt/tools/bin/../lib/gcc/../../lib/gcc/alpha-linux-gnu/14.2.0/include-fixed",
{st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
newfstatat(AT_FDCWD,
"/opt/tools/bin/../lib/gcc/../../lib/gcc/alpha-linux-gnu/14.2.0/../../../../alpha-linux-gnu/include",
{st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
newfstatat(AT_FDCWD, "/opt/usr/include", {st_mode=S_IFDIR|0755, st_size=12288,
...}, 0) = 0
newfstatat(AT_FDCWD, "1.c.gch", 0x7ffcf0cf4b70, 0) = -1 ENOENT (No such file or
directory)
openat(AT_FDCWD, "1.c", O_RDONLY|O_NOCTTY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=60, ...}) = 0
read(3, "#include \n#include
[Bug target/120513] Possible arch or configure issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #25 from Greg Chandler ---
ctrl-d at that read yielded this:
read(0, "", 8192) = 0
close(0)= 0
times({tms_utime=12 /* 0.012 s */, tms_stime=11 /* 0.011 s */, tms_cutime=0,
tms_cstime=0}) = 4297628950
times({tms_utime=12 /* 0.012 s */, tms_stime=11 /* 0.011 s */, tms_cutime=0,
tms_cstime=0}) = 4297628950
brk(0x12267c000)= 0x12267c000
getcwd("/tmp", 1024)= 5
readlink("/tmp/.s", 0x11fca9df0, 1023) = -1 EINVAL (Invalid argument)
getcwd("/tmp", 1024)= 5
readlink("/tmp/", 0x11fca9df0, 1023) = -1 ENOENT (No such file or
directory)
openat(AT_FDCWD, ".s", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 0
fstat64(0, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
times({tms_utime=69 /* 0.069 s */, tms_stime=17 /* 0.017 s */, tms_cutime=0,
tms_cstime=0}) = 4297629014
times({tms_utime=69 /* 0.069 s */, tms_stime=17 /* 0.017 s */, tms_cutime=0,
tms_cstime=0}) = 4297629015
fstatat64(AT_FDCWD, "/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...},
0) = 0
fstatat64(AT_FDCWD, ".", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}, 0)
= 0
times({tms_utime=69 /* 0.069 s */, tms_stime=17 /* 0.017 s */, tms_cutime=0,
tms_cstime=0}) = 4297629016
times({tms_utime=69 /* 0.069 s */, tms_stime=17 /* 0.017 s */, tms_cutime=0,
tms_cstime=0}) = 4297629016
times({tms_utime=69 /* 0.069 s */, tms_stime=17 /* 0.017 s */, tms_cutime=0,
tms_cstime=0}) = 4297629016
readlink("/usr", 0x11fca9bf0, 1023) = -1 EINVAL (Invalid argument)
readlink("/usr/lib", 0x11fca9bf0, 1023) = -1 EINVAL (Invalid argument)
readlink("/usr/lib/gcc", 0x11fca9bf0, 1023) = -1 EINVAL (Invalid argument)
readlink("/usr/lib/gcc/alpha-linux-gnu", 0x11fca9bf0, 1023) = -1 EINVAL
(Invalid argument)
readlink("/usr/lib/gcc/alpha-linux-gnu/14.2.0", 0x11fca9bf0, 1023) = -1 EINVAL
(Invalid argument)
readlink("/usr/lib/gcc/alpha-linux-gnu/14.2.0/include", 0x11fca9bf0, 1023) = -1
EINVAL (Invalid argument)
readlink("/usr/lib/gcc/alpha-linux-gnu/14.2.0/include/stdc-predef.h",
0x11fca9bf0, 1023) = -1 ENOENT (No such file or directory)
fstatat64(AT_FDCWD,
"/usr/lib/gcc/alpha-linux-gnu/14.2.0/include/stdc-predef.h.gch", 0x11fcab090,
0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/gcc/alpha-linux-gnu/14.2.0/include/stdc-predef.h",
O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
readlink("/usr", 0x11fca9bf0, 1023) = -1 EINVAL (Invalid argument)
readlink("/usr/local", 0x11fca9bf0, 1023) = -1 EINVAL (Invalid argument)
readlink("/usr/local/include", 0x11fca9bf0, 1023) = -1 EINVAL (Invalid
argument)
readlink("/usr/local/include/stdc-predef.h", 0x11fca9bf0, 1023) = -1 ENOENT (No
such file or directory)
fstatat64(AT_FDCWD, "/usr/local/include/stdc-predef.h.gch", 0x11fcab090, 0) =
-1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/local/include/stdc-predef.h", O_RDONLY|O_NOCTTY) = -1
ENOENT (No such file or directory)
readlink("/usr", 0x11fca9bf0, 1023) = -1 EINVAL (Invalid argument)
readlink("/usr/lib", 0x11fca9bf0, 1023) = -1 EINVAL (Invalid argument)
readlink("/usr/lib/gcc", 0x11fca9bf0, 1023) = -1 EINVAL (Invalid argument)
readlink("/usr/lib/gcc/alpha-linux-gnu", 0x11fca9bf0, 1023) = -1 EINVAL
(Invalid argument)
readlink("/usr/lib/gcc/alpha-linux-gnu/14.2.0", 0x11fca9bf0, 1023) = -1 EINVAL
(Invalid argument)
readlink("/usr/lib/gcc/alpha-linux-gnu/14.2.0/include-fixed", 0x11fca9bf0,
1023) = -1 EINVAL (Invalid argument)
readlink("/usr/lib/gcc/alpha-linux-gnu/14.2.0/include-fixed/stdc-predef.h",
0x11fca9bf0, 1023) = -1 ENOENT (No such file or directory)
fstatat64(AT_FDCWD,
"/usr/lib/gcc/alpha-linux-gnu/14.2.0/include-fixed/stdc-predef.h.gch",
0x11fcab090, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD,
"/usr/lib/gcc/alpha-linux-gnu/14.2.0/include-fixed/stdc-predef.h",
O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
readlink("/usr", 0x11fca9bf0, 1023) = -1 EINVAL (Invalid argument)
readlink("/usr/include", 0x11fca9bf0, 1023) = -1 EINVAL (Invalid argument)
readlink("/usr/include/stdc-predef.h", 0x11fca9bf0, 1023) = -1 EINVAL (Invalid
argument)
fstatat64(AT_FDCWD, "/usr/include/stdc-predef.h.gch", 0x11fcab090, 0) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/include/stdc-predef.h", O_RDONLY|O_NOCTTY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2462, ...}) = 0
read(3, "/* Copyright (C) 1991-2025 Free "..., 2462) = 2462
close(3)= 0
times({tms_utime=75 /* 0.075 s */, tms_stime=18 /* 0.018 s */, tms_cutime=0,
tms_cstime=0}) = 4297629030
times({tms_utime=75 /* 0.075 s */, tms_stime=18 /* 0.018 s */, tms_cutime=0,
tms_cstime=0}) = 4297629030
times({tms_utime=75 /* 0.075 s */, tms_stime=18 /* 0.018 s */, tms_cutime=0,
tms_cstime=0}) = 4297629031
times({tms_utime=75 /* 0.075 s */, tms_stime=18 /* 0.018 s */, tms_cutime=0,
tms_cstime=0}) = 4297629031
times({tms_utime=76 /* 0.076 s */, tms_stime=18 /* 0.018 s
[Bug middle-end/110459] Trivial on stack variable was not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110459 --- Comment #10 from Andrew Pinski --- (In reply to Andrew Pinski from comment #9) > Created attachment 61598 [details] > includes the fix for libstdc++ +FAIL: g++.dg/lto/pr107467 cp_lto_pr107467_0.o-cp_lto_pr107467_0.o link, -O2 -fno-strict-aliasing -flto (internal compiler error: in int_mode_for_mode, at stor-layout.cc:408) /home/apinski/src/upstream-gcc-isel/gcc/gcc/testsuite/g++.dg/lto/pr107467_0.C: In function 'get_const.isra': /home/apinski/src/upstream-gcc-isel/gcc/gcc/testsuite/g++.dg/lto/pr107467_0.C:21:34: internal compiler error: in int_mode_for_mode, at stor-layout.cc:408 0x239a6cf internal_error(char const*, ...) /home/apinski/src/upstream-gcc-isel/gcc/gcc/diagnostic-global-context.cc:517 0x995a93 fancy_abort(char const*, int, char const*) /home/apinski/src/upstream-gcc-isel/gcc/gcc/diagnostic.cc:1803 0x81b74f int_mode_for_mode(machine_mode) /home/apinski/src/upstream-gcc-isel/gcc/gcc/stor-layout.cc:408 0xb624e7 extract_bit_field_1 /home/apinski/src/upstream-gcc-isel/gcc/gcc/expmed.cc:1823 0xb63419 extract_bit_field(rtx_def*, poly_int<1u, unsigned long>, poly_int<1u, unsigned long>, int, rtx_def*, machine_mode, machine_mode, bool, rtx_def**) /home/apinski/src/upstream-gcc-isel/gcc/gcc/expmed.cc:2174 0xb67562 store_integral_bit_field /home/apinski/src/upstream-gcc-isel/gcc/gcc/expmed.cc:1012 0xb67562 store_bit_field_1 /home/apinski/src/upstream-gcc-isel/gcc/gcc/expmed.cc:891 0xb67f70 store_bit_field(rtx_def*, poly_int<1u, unsigned long>, poly_int<1u, unsigned long>, poly_int<1u, unsigned long>, poly_int<1u, unsigned long>, machine_mode, rtx_def*, bool, bool) /home/apinski/src/upstream-gcc-isel/gcc/gcc/expmed.cc:1213 0xb947e2 store_field /home/apinski/src/upstream-gcc-isel/gcc/gcc/expr.cc:8336 0xb90293 expand_assignment(tree_node*, tree_node*, bool) /home/apinski/src/upstream-gcc-isel/gcc/gcc/expr.cc:6334 0xb90293 expand_assignment(tree_node*, tree_node*, bool) /home/apinski/src/upstream-gcc-isel/gcc/gcc/expr.cc:5971 0xa50e19 expand_gimple_stmt_1 /home/apinski/src/upstream-gcc-isel/gcc/gcc/cfgexpand.cc:4289 0xa50e19 expand_gimple_stmt /home/apinski/src/upstream-gcc-isel/gcc/gcc/cfgexpand.cc:4370 0xa522fe expand_gimple_basic_block /home/apinski/src/upstream-gcc-isel/gcc/gcc/cfgexpand.cc:6433 0xa54316 execute /home/apinski/src/upstream-gcc-isel/gcc/gcc/cfgexpand.cc:7181 Wait I think I see my mistake, confusing bytes and bits.
[Bug middle-end/110459] Trivial on stack variable was not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110459 --- Comment #11 from Andrew Pinski --- s/TYPE_SIZE_UNIT/TYPE_SIZE/g in the patch :).
[Bug target/120513] Possible arch or configure issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #26 from Greg Chandler ---
root@bigbang:/tmp# /usr/libexec/gcc/alpha-linux-gnu/14.2.0/cc1 /tmp/1.c
__bswap_16 __bswap_32 __bswap_64 __uint16_identity __uint32_identity
__uint64_identity main
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> {heap 944k} {heap 944k}
{heap 944k} {heap 1136k} {heap 1136k}
{heap 1136k} {heap 1136k}Streaming LTO
{heap 1136k} {heap 1136k} {heap 1136k}
{heap 1136k} {heap 1136k} {heap 1136k}
{heap 1136k}Assembling functions:
main
Time variable usr sys wall
GGC
phase setup: 0.05 ( 18%) 0.00 ( 7%) 0.06 ( 15%)
1447k ( 58%)
phase parsing : 0.22 ( 73%) 0.06 ( 87%) 0.29 ( 76%)
1017k ( 41%)
phase opt and generate : 0.02 ( 8%) 0.00 ( 7%) 0.03 ( 8%)
46k ( 2%)
callgraph ipa passes : 0.00 ( 1%) 0.00 ( 3%) 0.01 ( 2%)
3960 ( 0%)
preprocessing : 0.11 ( 35%) 0.02 ( 29%) 0.13 ( 34%)
422k ( 17%)
lexical analysis : 0.01 ( 3%) 0.02 ( 32%) 0.04 ( 9%)
0 ( 0%)
parser (global): 0.08 ( 27%) 0.02 ( 24%) 0.09 ( 24%)
550k ( 22%)
parser struct body : 0.02 ( 7%) 0.00 ( 0%) 0.02 ( 6%)
35k ( 1%)
parser inl. func. body : 0.01 ( 2%) 0.00 ( 0%) 0.01 ( 2%)
7408 ( 0%)
initialize rtl : 0.01 ( 3%) 0.00 ( 0%) 0.01 ( 2%)
15k ( 1%)
TOTAL : 0.30 0.07 0.38
2510k
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.
root@bigbang:/tmp# cat 1.s
.set noreorder
.set volatile
.set noat
.set nomacro
.arch ev4
.text
.align 2
.globl main
.ent main
$main..ng:
main:
.frame $15,16,$26,0
.mask 0x4008000,-16
$LFB6:
.cfi_startproc
lda $30,-16($30)
.cfi_def_cfa_offset 16
stq $26,0($30)
stq $15,8($30)
.cfi_offset 26, -16
.cfi_offset 15, -8
mov $30,$15
.cfi_def_cfa_register 15
.prologue 0
mov $31,$1
mov $1,$0
mov $15,$30
ldq $26,0($30)
ldq $15,8($30)
lda $30,16($30)
.cfi_restore 15
.cfi_restore 26
.cfi_def_cfa 30, 0
ret $31,($26),1
.cfi_endproc
$LFE6:
.end main
.ident "GCC: (GNU) 14.2.0"
.section.note.GNU-stack,"",@progbits
[Bug target/120513] Possible arch or configure issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513 --- Comment #27 from Greg Chandler --- root@bigbang:/tmp# which as /usr/bin/as root@bigbang:/tmp# as -v GNU assembler version 2.44 (alpha-linux-gnu) using BFD version version 2.44-slack151 ^C root@bigbang:/tmp# as 1.s root@bigbang:/tmp# ls -al a.out -rwxr-xr-x 1 root root 1200 Jun 7 04:50 a.out* root@bigbang:/tmp# file a.out a.out: ELF 64-bit LSB relocatable, Alpha (unofficial), version 1 (SYSV), not stripped root@bigbang:/tmp# ldd a.out not a dynamic executable root@bigbang:/tmp# ./a.out -bash: ./a.out: cannot execute binary file: Exec format error
[Bug tree-optimization/120572] New: -Wmusttail-local-addr/-Wno-maybe-musttail-local-addr is incorrect in the index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120572 Bug ID: 120572 Summary: -Wmusttail-local-addr/-Wno-maybe-musttail-local-addr is incorrect in the index Product: gcc Version: 16.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: tree-optimization Assignee: pinskia at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Option-Index.html They are listed as -Wmusttail-local-addr and -Wno-maybe-musttail-local-addr rather than without the -. I will fix this tomorrow or so.
[Bug tree-optimization/120572] -Wmusttail-local-addr/-Wno-maybe-musttail-local-addr is incorrect in the index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120572 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2025-06-07 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- .
[Bug tree-optimization/120572] -Wmusttail-local-addr/-Wno-maybe-musttail-local-addr is incorrect in the index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120572 --- Comment #2 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:50ca15baa73a5687ff0d0207dc9313b3ae1d6e5c commit r16-1275-g50ca15baa73a5687ff0d0207dc9313b3ae1d6e5c Author: Andrew Pinski Date: Fri Jun 6 21:50:27 2025 -0700 Fix index of some warnings [PR120572] The problem here is opindex should not include the `-` part of the option. But Wmusttail-local-addr and Wno-maybe-musttail-local-addr currently do. This deletes them. Pushed as obvious after building the html. PR tree-optimization/120572 gcc/ChangeLog: * doc/invoke.texi (Wmusttail-local-addr, Wno-maybe-musttail-local-addr): Fix opindex. * common.opt.urls: Regenerate. Signed-off-by: Andrew Pinski
[Bug tree-optimization/120572] -Wmusttail-local-addr/-Wno-maybe-musttail-local-addr is incorrect in the index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120572 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |16.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Andrew Pinski --- Fixed, I thought I was going to do other stuff but I finished this up instead.
[Bug c/120573] New: Inconsistent array size overflow behavior between -O0 and others optimizations: code compiles at -O1、-O2、O3ad, but fails at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120573 Bug ID: 120573 Summary: Inconsistent array size overflow behavior between -O0 and others optimizations: code compiles at -O1、-O2、O3ad, but fails at -O0 Product: gcc Version: 14.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: 2023091106 at cauc dot edu.cn Target Milestone: ---
[Bug c/120573] Inconsistent array size overflow behavior between -O0 and others optimizations: code compiles at -O1、-O2、O3ad, but fails at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120573 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2025-06-07 --- Comment #1 from Andrew Pinski --- No body of the bug report? did you accidently press return too soon?
[Bug c++/120531] [13/14/15/16 Regression] ICE Segmentation fault in gimplify_expr since version 13.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120531
Andrew Pinski changed:
What|Removed |Added
Keywords|accepts-invalid |error-recovery,
||needs-bisection
Target Milestone|--- |13.5
Summary|ICE Segmentation fault in |[13/14/15/16 Regression]
|gimplify_expr since version |ICE Segmentation fault in
|13.1|gimplify_expr since version
||13.1
Last reconfirmed||2025-06-07
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from Andrew Pinski ---
There is an error before the ICE in all testcases I have tried.
Simplified testcase:
```
enum class E : float {
V1
};
template void f(U&&);
int main() {
f(E::V1);
}
```
[Bug c++/120531] [13/14/15/16 Regression] ICE Seg fault in gimplify_expr with enum with an invalid underlying type since version 13.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120531
--- Comment #3 from Andrew Pinski ---
The enum type looks like it was not "laid out".
This fixes the ICE but I am not 100% sure if it is the correct fix:
```
[apinski@xeond2 gcc]$ git diff
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 9a20ed62738..5d8af6dd8f8 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -17736,6 +17736,7 @@ start_enum (tree name, tree enumtype, tree
underlying_type,
{
error ("underlying type %qT of %qT must be an integral type",
underlying_type, enumtype);
+ copy_type_enum (enumtype, integer_type_node);
ENUM_UNDERLYING_TYPE (enumtype) = integer_type_node;
}
}
```
[Bug c/120574] New: Inconsistent array size overflow behavior between -O0 and others optimizations: code compiles at -O1、-O2、O3, but fails at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120574
Bug ID: 120574
Summary: Inconsistent array size overflow behavior between -O0
and others optimizations: code compiles at -O1、-O2、O3,
but fails at -O0
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 2023091106 at cauc dot edu.cn
Target Milestone: ---
When compiling the following code using GCC with different optimization levels,
-O0 results in a compilation error due to excessive local object size, while
-O1 or other optimizations and above compile and run successfully. This
inconsistency may hide bugs or undefined behavior depending on optimization
flags.
Tested with: gcc (GCC) 12/13/14
the gcc code
#include
void a(void) {
puts("A");
}
void b() {
char arr[(size_t)-1 / 2]; // Test for large array allocation issues
arr[(size_t)-1 / 2]='a';
printf("Array size: %zu\n", sizeof(arr));
}
void c() {
int arr[((size_t)-1)/2 / sizeof(int)]; // Test for integer division and
overflow
arr[((size_t)-1)/2 / sizeof(int)]='a';
printf("Integer array size: %zu\n", sizeof(arr));
}
int main(void)
{
b();
c();
}
output
$ gcc-14 -Wall -Wextra -O0 -o test test.c
test.c: 在function ‘b’中:
test.c:7:6: error：total size of local objects 9223372036854775808 exceeds
maximum 9223372036854775296
7 | void b() {
| ^
test.c: in function ‘c’中:
test.c:13:6: error：total size of local objects 9223372036854775808 exceeds
maximum 9223372036854775296
13 | void c() {
| ^
$ gcc-14 -Wall -Wextra -O1 -o test test.c
$ ./test
Array size: 9223372036854775807
Integer array size: 9223372036854775804
the gcc versions=
$ gcc-14 -v
Using built-in specs.
COLLECT_GCC=gcc-14
COLLECT_LTO_WRAPPER=/opt/gcc-14/libexec/gcc/x86_64-pc-linux-gnu/14.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/opt/gcc-14 --enable-languages=c,c++
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.1.0 (GCC)
[Bug c/120573] Inconsistent array size overflow behavior between -O0 and others optimizations: code compiles at -O1、-O2、O3ad, but fails at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120573 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- . *** This bug has been marked as a duplicate of bug 120574 ***
[Bug c/120574] Inconsistent array size overflow behavior between -O0 and others optimizations: code compiles at -O1、-O2、O3, but fails at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120574 --- Comment #1 from Andrew Pinski --- *** Bug 120573 has been marked as a duplicate of this bug. ***
[Bug c/120570] New: -pedantic option may not direct GCC to print a warning message if __attribute__ feature is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120570 Bug ID: 120570 Summary: -pedantic option may not direct GCC to print a warning message if __attribute__ feature is used Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pavel.morozkin at gmail dot com Target Milestone: --- GCC documentation (https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html) says: > GNU C provides several language features not found in ISO standard C. (The > -pedantic option directs GCC to print a warning message if any of these > features is used.) For Common Function Attribute (https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html) __attribute__ ((access (read_only, 1))) -pedantic option may not direct GCC to print a warning message. Example: __attribute__ ((access (read_only, 1))) int puts (const char* x); compiled with GCC 14.1 with options -O3 -std=c11 -pedantic -Wall -Wextra does not produce a warning. Per ISO C11 the code above may lead to syntax error, which is required to be diagnosed.
[Bug c/120570] -pedantic option may not direct GCC to print a warning message if __attribute__ feature is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120570 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Andrew Pinski --- Since __ is the implementation space, we don't error out on purpose.
[Bug libgomp/93226] OpenACC 2.6: acc_memcpy_device runtime function missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93226 --- Comment #6 from Tobias Burnus --- (In reply to Thomas Schwinge from comment #5) > On OG15, for both nvptx and GCN offloading, I see: ... The code has in the module: integer :: D(N) !$acc declare device_resident(D) The problem is that on OG15, the compiler inserts at the beginning of the main program: #pragma omp target oacc_data map(force_alloc:d [len: 4096]) Thus, the variable is registered twice: Once through GOMP_offload_register_ver and then through GOACC_data_start leading to libgomp: Trying to map into device [0x65d240..0x65e240) object when [0x65d240..0x65e240) is already mapped I bet that's a side-effect of commit e361f9db605 Fortran "declare create"/allocate support for OpenACC Maybe something like the following is needed? (Light testing indicates that it fixes the issue.) --- a/gcc/fortran/trans-openmp.cc +++ b/gcc/fortran/trans-openmp.cc @@ -4737,4 +4737,8 @@ gfc_trans_omp_clauses (stmtblock_t *block, gfc_omp_clauses prev = n; + if (cd == TOC_OPENACC_DECLARE + && n->sym->attr.oacc_declare_device_resident) + continue; + /* We do not want to include allocatable vars in a synthetic "acc data" region created for "!$acc declare create" vars.
[Bug c++/120555] [15/16 Regression] Use of auto func before deduction of auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120555 Jason Merrill changed: What|Removed |Added Last reconfirmed||2025-06-06 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/120570] -pedantic option may not direct GCC to print a warning message if __attribute__ feature is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120570 --- Comment #2 from Pavel M --- (In reply to Andrew Pinski from comment #1) > Since __ is the implementation space, we don't error out on purpose. Then why does "__int128 x;" lead to "warning: ISO C does not support '__int128' types [-Wpedantic]"?
[Bug c++/120569] New: Valid C++14 (or C++11/C++98) incorrectly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120569
Bug ID: 120569
Summary: Valid C++14 (or C++11/C++98) incorrectly rejected
Product: gcc
Version: 16.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: ---
// { dg-do compile }
// { dg-options "" }
// { dg-additional-options "-pedantic" { target c++14 } }
namespace U {
struct A {};
struct A override {}; // { dg-warning "extended initializer lists
only available with" "" { target c++98_only } }
}
namespace V {
template
struct B {};
template
struct B override {}; // { dg-warning "extended initializer lists
only available with" "" { target c++98_only } }
} // { dg-warning "variable templates only
available with" "" { target c++11_down } .-1 }
struct C {
struct D {};
struct D override {}; // { dg-warning "extended initializer lists
only available with" "" { target c++98_only } }
}; // { dg-warning "non-static data member
initializers only available with" "" { target c++98_only } .-1 }
namespace W {
struct E { struct F {}; };
struct E::F override {}; // { dg-warning "extended initializer lists
only available with" "" { target c++98_only } }
}
template
struct V::B override {}; // { dg-warning "extended initializer lists
only available with" "" { target c++98_only } }
// { dg-warning "variable templates only
available with" "" { target c++11_down } .-1 }
is accepted by clang++ but incorrectly rejected by GCC.
[Bug c++/120569] Valid C++14 (or C++11/C++98) incorrectly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120569 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Keywords||rejects-valid Last reconfirmed||2025-06-06 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug c++/120569] Valid C++14 (or C++11/C++98) incorrectly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120569 --- Comment #1 from Jakub Jelinek --- Created attachment 61596 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61596&action=edit gcc16-pr120569.patch Untested fix.
[Bug target/120513] Possible arch or configure issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #20 from Greg Chandler ---
After a marathon of table-flipping and much ado, I was able to get all the
dependcies I needed for gdb to work. So that was the good news..
The bad news is that with gdb I am still staring at this process wait...
I took a very long walk and was thinking about a patch I wrote for the IRIX
kernel and supporting libraries back in '99. There were two sections of
distinct runtime. Multiprocessor and Uniproccessor.. If you ran
multiprocessor code on a uniprocessor machine say like a r4400
(Indy/Indigo/etc) you ended up with a spin lock waiting for a thread that you
would never get because the system wasn't using proper threads. As big as a
headache as that was I didn't really remember it until now.
So... I figured you know what? Lets enable threads on my cross-compiler,
because I need libgcrypt anyway
So I did. And a LOT of things happened all at once.. Firstly I no longer
get a not supported issue with stack-protector... Secondly the
fstack-protector messages no longer show up... Which leads me to beleive that
there is a very specific depenency on threads that may not be being checked as
well as it should at configure time.
This yields a working gcc that I was able to compile libgcrypt with (had not
been able to before because of a lack of thread local storage) and that was
really nice.
What it also yeilded was a broken g++:
For this program:
int main ()
{
}
root@constellation:/tmp# gcc 2.cpp
root@constellation:/tmp# file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked,
interpreter /lib64/ld-linux-x86-64.so.2, with debug_info, not stripped
root@constellation:/tmp# rm a.out
root@constellation:/tmp# alpha-linux-gnu-gcc 2.cpp
root@constellation:/tmp# file a.out
a.out: ELF 64-bit LSB pie executable, Alpha (unofficial), version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2, with debug_info, not
stripped
root@constellation:/tmp# rm a.out
root@constellation:/tmp# alpha-linux-gnu-g++ 2.cpp
/opt/tools/bin/../lib/gcc/alpha-linux-gnu/14.2.0/../../../../alpha-linux-gnu/bin/ld:
a.out: hidden symbol `_Unwind_GetLanguageSpecificData' in
/opt/tools/bin/../lib/gcc/alpha-linux-gnu/14.2.0/libgcc.a(unwind-dw2.o) is
referenced by DSO
/opt/tools/bin/../lib/gcc/alpha-linux-gnu/14.2.0/../../../../alpha-linux-gnu/bin/ld:
final link failed: bad value
collect2: error: ld returned 1 exit status
So, I need to go back and take a closer look at that now, I also enabled
libatomic, libgomp, libquadmath, libssp, and libvtv because I did not notice
the broken g++ right away, so I need to figure out which or which combination
of those and threads broke it.
I have a very bad hunch that once I get this sorted out, the thread support is
going to fix the problem I've been seeing with the native compiler I've been
trying to build, and I am not looking forward to troubleshooting that mess.
[Bug debug/120571] New: emit DWARF type declarations for incomplete types in headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120571
Bug ID: 120571
Summary: emit DWARF type declarations for incomplete types in
headers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: woodard at redhat dot com
Target Milestone: ---
Consider:
impl.h:
struct Point;
int dist(struct Point p1, struct Point p2);
struct Point mid(struct Point p1, struct Point p2);
extern struct Point ORIGIN;
and v1.c:
#include "impl.h"
struct Point {
int x, y;
};
struct Point ORIGIN = (struct Point){0, 0};
int dist(struct Point p1, struct Point p2) {
return 0;
}
struct Point mid(struct Point p1, struct Point p2) {
return ORIGIN;
}
Currently the DWARF sets the declaration coordinates to the definition rather
than the original declaration found in the header file.
<1><2e>: Abbrev Number: 4 (DW_TAG_structure_type)
<2f> DW_AT_name: (indirect string, offset: 0x79): Point
<33> DW_AT_byte_size : 8
<34> DW_AT_decl_file : 1
<35> DW_AT_decl_line : 3
<36> DW_AT_decl_column : 8
We would also like to have gcc emit DWARF fir the incomplete declaration found
in the header file which we think would look something like this with the
DW_AT_declaration flag set:
<1><2e>: Abbrev Number: 4 (DW_TAG_structure_type)
<2f> DW_AT_name: (indirect string, offset: 0x79): Point
<34> DW_AT_decl_file : 2
<35> DW_AT_decl_line : 1
<36> DW_AT_decl_column : 12
DW_AT_declaration : 1
Of course this would not include the data members because they would not have
been defined yet. I think at some point long ago GCC did emit these but it was
removed as a response to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55059
However, we have a good use case where the information would be necessary:
We would like to be able to do something like:
$ abidiff --header-file1 test/include/public-api.h /usr/lib64/libproject.so
test/lib/libproject.so
When the user specifies a header file with --header-file1 then the types,
variables and functions which are not explicitly declared in the specified
header files are suppressed by default because they are implementation details.
While only the types, varibles and functions originally declared in a public
header are considered for ABI analysis. Currently, this cannot be done because
the DWARF only points to the definition of the type not the original incomplete
declaration of the type. So there is no way to identify from the existing DWARF
if the file was originally declared in the header file.
The problem is, the DWARF currently only points to the definition which is in
the C files, it doesn't enumerate the incomplete declarations in the header
files. If we had both the location of the incomplete declaration in the header
and the definition in the C file then ABI analysis tools such as libabigail
could automatically tell which functions, varibles and types are part of the
library's public API simply by virtue of the header it is in. This would
greatly simplify the process of verifying that the ABI of libraries are not
changing over time.
The current workaround is very cumbersome, a bespoke libabigail suppression
file must be created and maintained for each library which is part of our
collection of software. The mainual effort required to do this makes that
workaround unfeasible at a large scale.
To minimize the volume of additional DWARF being generated It is perfectly
acceptable to have this behavior only happen when requested with something
like: -gincomplete-types or have it rolled up when there extra debug
information is generated with an option like -g3. This should also help
minimize the impact on other tools which might have trouble dealing with the
DWARF having both an incomplete type for the declaration marked with
DW_AT_declaration and a full type definition.
Tools which only need the full type definition can be taught to ignore
functions, variables, and types which include DW_AT_declaration and to assist
them in finding the full type definition DW_AT_sibling can be emitted in the
incomplete declaration to point them from the incomplete type to the full type
definition.
[Bug target/120513] Possible arch or configure issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513 --- Comment #21 from Greg Chandler --- As I typed out that last message, it dawned on me that libssp is the likely cause of the stack protection stuff... (sigh)
[Bug debug/120571] emit DWARF type declarations for incomplete types in headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120571
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
If you just compile the header or a trivial TU that includes it (without the
part that defines the type), at least with -fno-eliminate-unused-debug-types
-fno-eliminate-unused-debug-symbols you get the DW_AT_declaration for it
(though it seems we don't add DW_AT_decl_{file,line,column} in that case).
Emitting both a DIE for the forward declaration (and any number of them?) at
least by default would be very wasteful.
[Bug target/120513] Possible arch or configure issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513 --- Comment #22 from Greg Chandler --- Well, I guess the next thing I needed to do was chug my morning cup of cherry coke to wake up... Since I was too tired to catch it last night, and clearly not paying attention this morning. The linker error was due to the --diable-shared, and some legacy files. So with a reverse of that flag, I have a non-erroring working cross again: for x in gcc alpha-linux-gnu-gcc alpha-linux-gnu-g++ ; do $x 2.cpp ; file a.out ; rm a.out ; done a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, with debug_info, not stripped a.out: ELF 64-bit LSB pie executable, Alpha (unofficial), version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, with debug_info, not stripped a.out: ELF 64-bit LSB pie executable, Alpha (unofficial), version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, with debug_info, not stripped Guess it's time for the big plunge on the native build..
[Bug c/120570] -pedantic option may not direct GCC to print a warning message if __attribute__ feature is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120570 --- Comment #3 from Andrew Pinski --- (In reply to Pavel M from comment #2) > (In reply to Andrew Pinski from comment #1) > > Since __ is the implementation space, we don't error out on purpose. > Then why does "__int128 x;" lead to "warning: ISO C does not support > '__int128' types [-Wpedantic]"? Because that is different. For most attributes it does not change the meaning and you could use do: #define __attribute__(a) Which is why there are two (( around the attribute part :).
[Bug debug/120571] emit DWARF type declarations for incomplete types in headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120571 --- Comment #2 from Ben Woodard --- Yes a partial workaround could be something like: gcc -g -fno-eliminate-unused-debug-types -include impl.h -xc /dev/null -c -o FOO.o which will emit the type and the variable but still doesn't give us the declaration coordinates of the function prototypes. (2 of the 3 things that I need) Contents of the .debug_info section: Compilation Unit @ offset 0: Length:0x2c (32-bit) Version: 5 Unit Type: DW_UT_compile (1) Abbrev Offset: 0 Pointer Size: 8 <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_producer: (indirect string, offset: 0xd): GNU C17 14.2.1 20250110 (Red Hat 14.2.1-7) -mtune=generic -march=x86-64-v3 -g -fno-eliminate-unused-debug-types <11> DW_AT_language: 29 (C11) <12> DW_AT_name: (indirect line string, offset: 0x17): /dev/null <16> DW_AT_comp_dir: (indirect line string, offset: 0): /home/ben/Work/abidiff <1a> DW_AT_stmt_list : 0 <1><1e>: Abbrev Number: 2 (DW_TAG_structure_type) <1f> DW_AT_name: (indirect string, offset: 0): Point <23> DW_AT_declaration : 1 <1><23>: Abbrev Number: 3 (DW_TAG_variable) <24> DW_AT_name: (indirect string, offset: 0x6): ORIGIN <28> DW_AT_decl_file : 1 <29> DW_AT_decl_line : 4 <2a> DW_AT_decl_column : 21 <2b> DW_AT_type: <0x1e> <2f> DW_AT_external: 1 <2f> DW_AT_declaration : 1 <1><2f>: Abbrev Number: 0 -fno-eliminate-unused-debug-symbols still doesn't emit the function declaration coordinates. The output is the same as above. If there was an option like: -gno-eliminate-function-prototypes Then we probably would have everything we need. I didn't see anything like that when scrolling through the -f and the -g options in the invoking GCC option index page but there are a huge number of options and I could have missed something. As for being wasteful, it certainly doesn't need to be the default. We are completely fine having this behavior turned on only under the control of a command line argument. Some suggestions are: Add -gno-eliminate-function-prototypes extending -fno-eliminate-unused-debug-symbols so that it also includes function prototypes Add -gincomplete-declarations or -gno-eliminate-incomplete-declarations (which would basically be the same as -fno-eliminate-unused-debug-types and either an extended -fno-eliminate-unused-debug-symbols or something like -gno-eliminate-function-prototypes or add it to -g3 which is users kind of understand as "give me everything you've got, I don't care how big the .debug_info" section ends up being."
[Bug c/120566] New: Possible memory leak in set_multilib_dir at gcc.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120566 Bug ID: 120566 Summary: Possible memory leak in set_multilib_dir at gcc.cc Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: shuhaofu.g at gmail dot com Target Milestone: --- Affected commit: 34701fe95d3f3b4e9f8056ce32e7f699f8441e7f at Github Mirror Within the function `set_multilib_dir`, if this branch condition (https://github.com/gcc-mirror/gcc/blob/34701fe95d3f3b4e9f8056ce32e7f699f8441e7f/gcc/gcc.cc#L9973) evaluates to true, ptr `p` gets pointed to a heap memory address with the function `concat`. For the rest of the function `set_multilib_dir`, this heap memory has not been freed properly.
[Bug tree-optimization/120032] Fails to pattern match clz from DeBruijn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120032 --- Comment #6 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4a80eaefd93c2f1f7c9b71dbc1b97783214b7b2f commit r16-1202-g4a80eaefd93c2f1f7c9b71dbc1b97783214b7b2f Author: Richard Biener Date: Thu Jun 5 14:23:06 2025 +0200 tree-optimization/120032 - CLZ matching, fallback for missing range-info The following allows us to emit a conditional move when the value of the table based CLZ/CLZ implementation at zero differs from what the target implementation guarantees or we cannot easily fixup otherwise. In that case emit a val == 0 ? table-based-zero-result : ... PR tree-optimization/120032 * tree-ssa-forwprop.cc (simplify_count_zeroes): When we cannot use the IFN to determine the result at zero use a conditional move to reproduce the correct result from the table-based algorithm. * gcc.target/i386/pr120032-3.c: New testcase.
[Bug tree-optimization/120032] Fails to pattern match clz from DeBruijn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120032 --- Comment #5 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:c6eb92973ea308e248ce23927a9ac58ef81ee7a2 commit r16-1201-gc6eb92973ea308e248ce23927a9ac58ef81ee7a2 Author: Richard Biener Date: Wed May 28 15:09:19 2025 +0200 tree-optimization/120032 - matching of table based CLZ The following adds the ability to match a table based CLZ implementation similar as to how we can do for CTZ. I'm re-using the workers for matching up array and string tables by using a lambda and templates and kept the transform step for CLZ/CTZ inter-mangled. PR tree-optimization/120032 * match.pd (clz_table_index): New match. * tree-ssa-forwprop.cc (check_table_array): Rename from check_ctz_array. Split out actual verification to a functor. (check_table_string): Rename from check_ctz_string and likewise. (check_table): Rename from check_ctz_table and adjust. (gimple_clz_table_index): Declare. (simplify_count_zeroes): Rename from simplify_count_trailing_zeroes. Extend to cover CLZ. (pass_forwprop::execute): Adjust. * gcc.target/i386/pr120032-1.c: New testcase. * gcc.target/i386/pr120032-2.c: Likewise.
[Bug tree-optimization/120032] Fails to pattern match clz from DeBruijn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120032 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Richard Biener --- This is now fixed.
[Bug tree-optimization/119960] [15 Regression] vectorizer seems not to do as much any more since r15-5863
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119960 --- Comment #12 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:05ef04d644c1a460b3af266a7766001c93fe1a6a commit r15-9780-g05ef04d644c1a460b3af266a7766001c93fe1a6a Author: Richard Biener Date: Tue Apr 29 15:08:52 2025 +0200 tree-optimization/119960 - add validity checking to SLP scheduling The following adds checks that when we search for a vector stmt insert location we arrive at one where all required operand defs are dominating the insert location. At the moment any such failure only blows up during SSA verification. There's the long-standing issue that we do not verify there exists a valid schedule of the SLP graph from BB vectorization into the existing CFG. We do not have the ability to insert vector stmts on the dominance frontier "end", nor to insert LC PHIs that would be eventually required. This should be done all differently, computing the schedule during analysis and failing if we can't schedule. PR tree-optimization/119960 * tree-vect-slp.cc (vect_schedule_slp_node): Sanity check dominance check on operand defs. (cherry picked from commit 5f44fcdfe18e72f2900d2757375843e88d32c535)
[Bug tree-optimization/120003] [12/13/14/15 Regression] missed optimization around a loop with a checker since r12-3453-g01b5038718056b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120003 --- Comment #12 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:ca8032d6177668ca7f2a6a2e612e126a97ba8c53 commit r15-9784-gca8032d6177668ca7f2a6a2e612e126a97ba8c53 Author: Richard Biener Date: Thu May 1 13:56:25 2025 +0200 Fix gcc.dg/tree-ssa/ssa-dom-thread-7.c for aarch64 So on another machine with a cross I see 17 jumps threaded, so adjusted like that. PR tree-optimization/120003 * gcc.dg/tree-ssa/ssa-dom-thread-7.c: Adjust aarch64 expected thread2 number of threads. (cherry picked from commit aa6f1df4ec46a20d2292291b192d3331e51b59f8)
[Bug tree-optimization/119960] [15 Regression] vectorizer seems not to do as much any more since r15-5863
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119960 Richard Biener changed: What|Removed |Added Known to fail||15.1.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Richard Biener --- Fixed.
[Bug tree-optimization/120357] [14/15 Regression] ICE in vect "error: definition in block 9 does not dominate use in block 3" with early break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357 --- Comment #11 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:8cb0127dfd3d01d4549f3139b087d1a5966844ee commit r15-9787-g8cb0127dfd3d01d4549f3139b087d1a5966844ee Author: Richard Biener Date: Fri May 30 14:11:47 2025 +0200 tree-optimization/120357 - ICE with early break vectorization When doing early break vectorization of a loop with a conditional reduction the epilog creation code is confused as to before which exit to insert the conditional reduction induction IV update. The following make sure this is done before the main IV exit. PR tree-optimization/120357 * tree-vect-loop.cc (vect_create_epilog_for_reduction): Create the conditional reduction induction IV increment before the main IV exit. * gcc.dg/vect/vect-early-break_136-pr120357.c: New testcase. (cherry picked from commit dce4da51ab66c3abb84448326910cd42f6fe2499)
[Bug middle-end/120434] GCC uses signed extend (movsxd) for known positive variables rather than zero extend 'mov'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120434 Jakub Jelinek changed: What|Removed |Added Attachment #61587|0 |1 is obsolete|| --- Comment #10 from Jakub Jelinek --- Created attachment 61592 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61592&action=edit gcc16-pr120434-1.patch Full patch (part 1/3) I'm testing right now.
[Bug middle-end/120434] GCC uses signed extend (movsxd) for known positive variables rather than zero extend 'mov'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120434 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #11 from Jakub Jelinek --- Created attachment 61593 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61593&action=edit gcc16-pr120434-2.patch Part 2/3
[Bug middle-end/120434] GCC uses signed extend (movsxd) for known positive variables rather than zero extend 'mov'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120434 --- Comment #12 from Jakub Jelinek --- Created attachment 61594 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61594&action=edit gcc16-pr120434-3.patch Part 3/3.
[Bug tree-optimization/113239] [13/14 regression] After r13-6372-g822a11a1e642e0, bogus -Warray-bounds warnings in std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113239 --- Comment #16 from Dimitry Andric --- (In reply to Jonathan Wakely from comment #15) > This makes the compiler shut up: Thank you, I can confirm that. I tried Ubuntu's g++-13 (Ubuntu 13.3.0-6ubuntu2~24.04) and g++-14 (Ubuntu 14.2.0-4ubuntu2~24.04) but edited their stl_vector.h files as you indicated. It looks like there are similar methods calling __uninitialized_copy_a below, so maybe this addition is also needed for those?
[Bug libstdc++/120432] flat_map operator[] is broken for const lvalue keys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120432 --- Comment #7 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:91ed3248ce26aaaee4d7471aa4edbc07b3f1a90e commit r16-1259-g91ed3248ce26aaaee4d7471aa4edbc07b3f1a90e Author: Patrick Palka Date: Fri Jun 6 09:34:17 2025 -0400 libstdc++: Fix flat_map::operator[] for const lvalue keys [PR120432] The const lvalue operator[] overload wasn't properly forwarding the key type to the generic overload, causing a hard error for const keys. Rather than correcting the forwarded type this patch just makes the non-template overloads call try_emplace directly instead. That way we can remove the non-standard same_as constraint on the generic overload and match the spec more closely. PR libstdc++/120432 libstdc++-v3/ChangeLog: * include/std/flat_map (flat_map::operator[]): Make the non-template overloads call try_emplace directly. Remove non-standard same_as constraint on the template overload. * testsuite/23_containers/flat_map/1.cc (test08): New test. Reviewed-by: Tomasz KamiÅski Reviewed-by: Jonathan Wakely
[Bug target/120530] nvptx offloading: FAIL: libgomp.c/target-map-zero-sized-3.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120530 Tobias Burnus changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Tobias Burnus --- FIXED on mainline (GCC 16). Thanks for the report and for testing!
[Bug libstdc++/120567] [16 Regression] std::stacktrace tests now fail on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120567 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2025-06-06 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- (In reply to Richard Earnshaw from comment #1) > Or you could configure your compiler with --with-arch=armv7-a or some other > v7 variant; at that point the default sync_synchronize can just do what's > needed without the need for user intervention. I didn't see the errors myself, they were in the Linaro CI results, so I can't change the config :-) Maybe filtering the messages out for those tests is the best option.
[Bug debug/120568] New: Small oversight in dwarf2out.cc:attr_checksum_ordered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120568 Bug ID: 120568 Summary: Small oversight in dwarf2out.cc:attr_checksum_ordered Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- I noticed this code in dwarf2out.cc:attr_checksum_ordered: case dw_val_class_unsigned_const: case dw_val_class_unsigned_const_implicit: CHECKSUM_ULEB128 (DW_FORM_sdata); CHECKSUM_SLEB128 ((int) at->dw_attr_val.v.val_unsigned); break; I think that first checksum should use DW_FORM_udata. I would send a patch but I'm not really sure how to write a test for this.
[Bug debug/118837] Interpretation of DW_FORM_data*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118837
--- Comment #5 from Tom Tromey ---
> If the 64-bit value is
> negative, we emit DW_FORM_sdata, otherwise we emit whatever is smallest
> representation of the positive value (DW_FORM_data{1,2,4,8}, could perhaps
> use DW_FORM_udata).
I think I didn't properly understand this earlier.
If GCC emits "128" as "DW_FORM_data1 0x80", even for a could-be-signed
attribute, then that seems like a real problem.
I did find a spot where GCC does this:
if (bit_offset < 0)
add_AT_int (die, DW_AT_bit_offset, bit_offset);
else
add_AT_unsigned (die, DW_AT_bit_offset, (unsigned HOST_WIDE_INT)
bit_offset);
I looked at all calls to add_AT_unsigned and also found this applies
to DW_AT_data_member_location, DW_AT_const_value.
There's also this comment in add_scalar_info:
/* If HOST_WIDE_INT is big enough then represent the bound as
a constant value. We need to choose a form based on
whether the type is signed or unsigned. We cannot just
call add_AT_unsigned if the value itself is positive
(add_AT_unsigned might add the unsigned value encoded as
DW_FORM_data[1248]). Some DWARF consumers will lookup the
bounds type and then sign extend any unsigned values found
for signed types. This is needed only for
DW_AT_{lower,upper}_bound, since for most other attributes,
consumers will treat DW_FORM_data[1248] as unsigned values,
regardless of the underlying type. */
... which to me is just confirmation that this whole area is a mess.
[Bug debug/118837] Interpretation of DW_FORM_data*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118837
--- Comment #6 from Tom Tromey ---
I also looked through the LLVM DWARF writer.
In part it is a bit nicer because it does:
void DwarfUnit::addConstantValue(DIE &Die, bool Unsigned, uint64_t Val) {
// FIXME: This is a bit conservative/simple - it emits negative values always
// sign extended to 64 bits rather than minimizing the number of bytes.
addUInt(Die, dwarf::DW_AT_const_value,
Unsigned ? dwarf::DW_FORM_udata : dwarf::DW_FORM_sdata, Val);
}
That is, for this attribute at least, it doesn't try to compute
the narrowest possible form.
Looking at the other "confused" attributes:
if (Offset < 0)
addSInt(MemberDie, dwarf::DW_AT_bit_offset, dwarf::DW_FORM_sdata,
Offset);
else
addUInt(MemberDie, dwarf::DW_AT_bit_offset, std::nullopt,
(uint64_t)Offset);
.. i.e., LLVM does the same as GCC here.
And finally:
if (DD->getDwarfVersion() == 3)
addUInt(MemberDie, dwarf::DW_AT_data_member_location,
dwarf::DW_FORM_udata, OffsetInBytes);
else
addUInt(MemberDie, dwarf::DW_AT_data_member_location, std::nullopt,
OffsetInBytes);
... which is fine since it at least agrees with GCC that narrow
forms should not sign-extend.
[Bug libstdc++/105258] std::get_temporary_buffer() does not respect alignment (affects std::stable_sort())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105258 --- Comment #12 from Jonathan Wakely --- Note to self: this needs to be backported along with the fix for this issue: g:c795413cf3a879e1e9155774652180fb3fbf5830 And also the stl_tempbuf.h part of Bug 104395 which was not included in the gcc-13 backport
[Bug libstdc++/111077] atomic_ref compare_exchange_strong doesn't properly ignore padding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111077 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|13.5|14.0 Status|ASSIGNED|RESOLVED --- Comment #11 from Jonathan Wakely --- I'm not planning to backport this now, so fixed for 14.1
[Bug libstdc++/120565] Outputing sys_info, local_info as wchar_t is ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120565 Tomasz Kamiński changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tomasz Kamiński --- Fixed in v16.
[Bug tree-optimization/116352] [15 regression] ICE when building opencv-4.9.0 (error: definition in block 208 does not dominate use in block 188) since r15-2820-gab18785840d7b8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116352 --- Comment #23 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:7da2b6ddf3a8371b585595231cddcb1ad0942ea4 commit r15-9781-g7da2b6ddf3a8371b585595231cddcb1ad0942ea4 Author: Richard Biener Date: Thu May 8 10:56:16 2025 +0200 tree-optimization/116352 - amend previous fix The previous fix restricted external vector builds to defs from the same basic-block. That turns out too restrictive so we have to mitigate the original issue in a different way which is restricting it to the original case where all defs are in the same basic-block. PR tree-optimization/116352 * tree-vect-slp.cc (vect_build_slp_tree_2): When compressing operands from a two-operator node make sure the resulting operation does not mix defs from different basic-blocks. (cherry picked from commit 1e8bd720b1a618a39e2a41eec05e935c32d295f3)
[Bug tree-optimization/120341] [12/13/14/15 Regregression] wrong code at -O1 and above with "-fallow-store-data-races" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120341 --- Comment #7 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:09884fa0f90da67915245622254cdfb947b87d37 commit r15-9786-g09884fa0f90da67915245622254cdfb947b87d37 Author: Richard Biener Date: Fri May 30 13:47:55 2025 +0200 tree-optimization/120341 - stores into STRING_CSTs can trap The following fixes conditional store elimination and store motion so they consider stores to STRING_CSTs as trapping. PR tree-optimization/120341 * tree-ssa-loop-im.cc (can_sm_ref_p): STRING_CSTs are readonly. * tree-ssa-phiopt.cc (cond_store_replacement): Likewise. * gcc.dg/torture/pr120341-1.c: New testcase. * gcc.dg/torture/pr120341-2.c: Likewise. (cherry picked from commit 02c58bc4b0885f5b6f50033da35768ebe6c4a030)
[Bug tree-optimization/120003] [12/13/14 Regression] missed optimization around a loop with a checker since r12-3453-g01b5038718056b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120003 Richard Biener changed: What|Removed |Added Known to work||15.1.1 Summary|[12/13/14/15 Regression]|[12/13/14 Regression] |missed optimization around |missed optimization around |a loop with a checker since |a loop with a checker since |r12-3453-g01b5038718056b|r12-3453-g01b5038718056b Status|ASSIGNED|NEW Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #13 from Richard Biener --- Fixed for 15.2, not considering further backports.
[Bug c/120563] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_parser_omp_clause_reduction, at c/c-parser.cc:18549
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120563
--- Comment #1 from Anonymous ---
(In reply to Anonymous from comment #0)
> *
> **
> The compiler produces an internal error during tree_class_check_failed when
> compiling the provided code with the specified options.
> The issue can also be reproduced on Compiler Explorer.
>
> *
> **
> OS and Platform:
> # uname -a
> Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
> x86_64 x86_64 x86_64 GNU/Linux
> *
> **
> # g++ -v
> Using built-in specs.
> COLLECT_GCC=g++
> COLLECT_LTO_WRAPPER=/root/gdbtest/gcc/gcc-250601/libexec/gcc/x86_64-pc-linux-
> gnu/16.0.0/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: ../gcc/configure --prefix=/root/gdbtest/gcc/gcc-250601
> --enable-languages=c,c++ --disable-multilib --disable-bootstrap
> Thread model: posix
> Supported LTO compression algorithms: zlib
> gcc version 16.0.0 20250601 (experimental) (GCC)
> *
> **
> Program:
> #cat code.c
>
>
> #pragma omp declare reduction (+: struct S : merge (&omp_out, &omp_in))
> initializer (init (&omp_priv))
>
> void
> foo (struct S x)
> {
> #pragma omp taskgroup task_reduction (+: x)
> {
> #pragma omp task in_reduction (+: x)
> {
> x.a++;
> x.b++;
> }
> #pragma omp task in_reduction (+: x)
> {
> x.a += 4;
> x.b += 14;
> }
> #pragma omp task in_reduction (+: x)
> {
> x.a += 9;
> x.b += 19;
> }
> }
> if (x.a != 56 || x.b != 86)
> __builtin_abort ();
> }
>
>
> *
> **
> Command Lines:
> gcc code.c -pipe -MMD -MP -MQ ./ -MT test.o -MF test.d -c -o code_0.o
>
>
> : In function 'omp declare reduction +':
> :1:46: error: implicit declaration of function 'merge'
> [-Wimplicit-function-declaration]
> 1 | #pragma omp declare reduction (+: struct S : merge (&omp_out,
> &omp_in)) initializer (init (&omp_priv))
> | ^
> :1:86: error: implicit declaration of function 'init'
> [-Wimplicit-function-declaration]
> 1 | #pragma omp declare reduction (+: struct S : merge (&omp_out,
> &omp_in)) initializer (init (&omp_priv))
> |
> ^~~~
> : At top level:
> :4:15: error: parameter 1 ('x') has incomplete type
> 4 | foo (struct S x)
> | ~^
> : In function 'foo':
> :6:11: internal compiler error: tree check: expected class 'type',
> have 'exceptional' (error_mark) in c_parser_omp_clause_reduction, at
> c/c-parser.cc:18685
> 6 | #pragma omp taskgroup task_reduction (+: x)
> | ^~~
> 0x2505575 diagnostic_context::diagnostic_impl(rich_location*,
> diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
> (*) [1], diagnostic_t)
> ???:0
> 0x2526e26 internal_error(char const*, ...)
> ???:0
> 0x8fdebb tree_class_check_failed(tree_node const*, tree_code_class, char
> const*, int, char const*)
> ???:0
> 0xac1cbe c_parse_file()
> ???:0
> 0xb433d9 c_common_parse_file()
> ???:0
> Please submit a full bug report, with preprocessed source (by using
> -freport-bug).
> Please include the complete backtrace with any bug report.
> See
[Bug libstdc++/120567] [16 Regression] std::stacktrace tests now fail on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120567 --- Comment #1 from Richard Earnshaw --- Many fortran tests also use libbacktrace. So these days I just have site.exp: set board_info(arm-qemu,extra_ldflags) "--specs=sync-none.specs" In my bare-metal test configuration. That's enough for a single-threaded machine. Or you could filter out the warning from the messages. Or you could configure your compiler with --with-arch=armv7-a or some other v7 variant; at that point the default sync_synchronize can just do what's needed without the need for user intervention.
[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 #19 from dave.anglin at bell dot net --- On 2025-06-05 6:53 a.m., redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832 > > --- Comment #18 from Jonathan Wakely --- > Done on trunk, but this seems worth backporting because _TIME_BITS=64 has been > a thing for some time already. Yes please. Debian has been carry a broken fix for this since gcc-12.
