[Bug middle-end/121017] `__builtin_copysign(0.0, a)` should be optimized to 0.0 for -fno-signed-zeros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121017 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-07-10 --- Comment #1 from Richard Biener --- Confirmed.
[Bug tree-optimization/121020] [16 regression] genrecog miscompiled since r16-1624-g6deab186535a5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121020 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Priority|P3 |P1
[Bug target/114676] [12/13 Regression] DSE removes assignment that is used later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Known to work||12.4.1, 13.3.1 Known to fail||12.4.0, 13.3.0 --- Comment #22 from Richard Biener --- This looks fixed.
[Bug target/116363] gcc.c-torture/execute/conversion.c fails on H8/300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116363 --- Comment #1 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:e6f2daff77ee1f709105cb9f8e3e92f04c179431 commit r16-2173-ge6f2daff77ee1f709105cb9f8e3e92f04c179431 Author: Jan Dubiec Date: Thu Jul 10 07:41:08 2025 -0600 [PATCH] libgcc: PR target/116363 Fix SFtype to UDWtype conversion This patch fixes SFtype to UDWtype (aka float to unsigned long long) conversion on targets without DFmode like e.g. H8/300H. It solely relies on SFtype->UWtype and UWtype->UDWtype conversions/casts. The existing code in line 2218 (counter = a) assigns/casts a float which is *always* not lesser than Wtype_MAXp1_F to an UWtype int which of course does not have enough capacity. PR target/116363 libgcc/ChangeLog: * libgcc2.c (__fixunssfDI): Fix SFtype to UDWtype conversion for targets without LIBGCC2_HAS_DF_MODE defined
[Bug tree-optimization/121014] vectorizer uses RDIV_EXPR for integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121014 Robin Dapp changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||rdapp at gcc dot gnu.org --- Comment #3 from Robin Dapp --- Fixed on trunk. I don't suppose we want to backport this as it's pretty harmless (all div variants expand to u/sdiv anyway)?
[Bug tree-optimization/121014] vectorizer uses RDIV_EXPR for integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121014 --- Comment #2 from GCC Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:5aa21765236730c1772c19454cbb71365b84d583 commit r16-2175-g5aa21765236730c1772c19454cbb71365b84d583 Author: Robin Dapp Date: Wed Jul 9 15:58:05 2025 +0200 expand: ICE if asked to expand RDIV with non-float type. This patch adds asserts that ensure we only expand an RDIV_EXPR with actual float mode. It also replaces the RDIV_EXPR in setting a vectorized loop's length by EXACT_DIV_EXPR. The code in question is only used with length-control targets (riscv, powerpc, s390). PR target/121014 gcc/ChangeLog: * cfgexpand.cc (expand_debug_expr): Assert FLOAT_MODE_P. * optabs-tree.cc (optab_for_tree_code): Assert FLOAT_TYPE_P. * tree-vect-loop.cc (vect_get_loop_len): Use EXACT_DIV_EXPR.
[Bug target/118734] RISC-V: Vector broadcast via strided load.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118734 --- Comment #5 from GCC Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:dcba959fb30dc250eeb6fdd05aa878e5f1fc8c2d commit r16-2174-gdcba959fb30dc250eeb6fdd05aa878e5f1fc8c2d Author: Robin Dapp Date: Thu Jul 10 09:41:48 2025 +0200 RISC-V: Make zero-stride load broadcast a tunable. This patch makes the zero-stride load broadcast idiom dependent on a uarch-tunable "use_zero_stride_load". Right now we have quite a few paths that reach a strided load and some of them are not exactly straightforward. While broadcast is relatively rare on rv64 targets it is more common on rv32 targets that want to vectorize 64-bit elements. While the patch is more involved than I would have liked it could have even touched more places. The whole broadcast-like insn path feels a bit hackish due to the several optimizations we employ. Some of the complications stem from the fact that we lump together real broadcasts, vector single-element sets, and strided broadcasts. The strided-load alternatives currently require a memory_constraint to work properly which causes more complications when trying to disable just these. In short, the whole pred_broadcast handling in combination with the sew64_scalar_helper could use work in the future. I was about to start with it in this patch but soon realized that it would only distract from the original intent. What can help in the future is split strided and non-strided broadcast entirely, as well as the single-element sets. Yet unclear is whether we need to pay special attention for misaligned strided loads (PR120782). I regtested on rv32 and rv64 with strided_load_broadcast_p forced to true and false. With either I didn't observe any new execution failures but obviously there are new scan failures with strided broadcast turned off. PR target/118734 gcc/ChangeLog: * config/riscv/constraints.md (Wdm): Use tunable for Wdm constraint. * config/riscv/riscv-protos.h (emit_avltype_insn): Declare. (can_be_broadcasted_p): Rename to... (can_be_broadcast_p): ...this. * config/riscv/predicates.md: Use renamed function. (strided_load_broadcast_p): Declare. * config/riscv/riscv-selftests.cc (run_broadcast_selftests): Only run broadcast selftest if strided broadcasts are OK. * config/riscv/riscv-v.cc (emit_avltype_insn): New function. (sew64_scalar_helper): Only emit a pred_broadcast if the new tunable says so. (can_be_broadcasted_p): Rename to... (can_be_broadcast_p): ...this and use new tunable. * config/riscv/riscv.cc (struct riscv_tune_param): Add strided broad tunable. (strided_load_broadcast_p): Implement. * config/riscv/vector.md: Use strided_load_broadcast_p () and work around 64-bit broadcast on rv32 targets.
[Bug target/118734] RISC-V: Vector broadcast via strided load.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118734 Robin Dapp changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Robin Dapp --- Should be fixed on trunk. I didn't do a comprehensive review of all broadcast vlses, though. In case we still have remains we can open a new bug.
[Bug target/109285] Unused variable in function __fixunssfdi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109285 Jan Dubiec changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=116363 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jan Dubiec --- Fixed in r16-2173-ge6f2daff77ee1f709105cb9f8e3e92f04c179431.
[Bug middle-end/120987] [14/15/16 regression] gdb build with lto triggers use after free since r14-5831-gaae723d360ca26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #11 from Tom de Vries ---
I build with -fdump-tree-all -fdump-ipa-all -fdump-rtl-all, resulting in a
rather large build:
...
$ du -hs build/
107Gbuild/
...
At gdb.ltrans58.ltrans.134t.bitintlower1, I have in parse_linespec:
...
[local count: 413228]:
# DEBUG BEGIN_STMT
throw_exception (&file_exception);
...
and:
...
[count: 0]:
:
_143 = MEM[(struct __shared_count *)&file_exception + 16B]._M_pi;
if (_143 != 0B)
goto ; [0.00%]
else
goto ; [0.00%]
[count: 0]:
_M_release (_143);
[count: 0]:
file_exception ={v} {CLOBBER(eob)};
# DEBUG this => NULL
resx 2
...
At gdb.ltrans58.ltrans.135t.sra, I have:
...
[local count: 413228]:
MEM [(struct gdb_exception *)&file_exception] =
file_exception_611;
MEM [(struct gdb_exception *)&file_exception +
16B] = file_exception$16$_M_pi_553;
throw_exception (&file_exception);
...
and:
...
_143 = file_exception$16$_M_pi_267;
...
which is defined by a phi:
...
[count: 0]:
# file_exception$16$_M_pi_267 = PHI
...
I'm not sure how to read this. There's an incoming edge from bb231, while
throw_exception doesn't return. If that is an incoming edge for the resulting
uncaught exception, then the value file_exception$16$_M_pi_553 is wrong.
The actual value of file_exception is in memory, as updated by throw_exception.
[Bug middle-end/120987] [14/15/16 regression] gdb build with lto triggers use after free since r14-5831-gaae723d360ca26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987 --- Comment #12 from Tom de Vries --- Created attachment 61832 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61832&action=edit gdb.ltrans58.ltrans.134t.bitintlower1.gz
[Bug middle-end/120987] [14/15/16 regression] gdb build with lto triggers use after free since r14-5831-gaae723d360ca26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987 --- Comment #13 from Tom de Vries --- Created attachment 61833 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61833&action=edit gdb.ltrans58.ltrans.135t.sra.gz
[Bug middle-end/63311] [12 Regression] -O1 optimization introduces valgrind warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63311 Richard Biener changed: What|Removed |Added Target Milestone|12.5|13.2 Known to fail||12.5.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #27 from Richard Biener --- Fixed in GCC 13.2.
[Bug tree-optimization/121029] GCC does not vectorize conditional min/max reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121029
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2025-07-11
--- Comment #1 from Richard Biener ---
I'd have expected if-conversion to turn this into .COND_MAX, but this doesn't
happen it seems, but I do see cond_[us]{min,max} patterns for AVX512.
Needs investigation why ifcvt doesn't handle this.
[Bug target/121025] New: [7.0 Regression] macOS ld sysroot delegation breaks libtool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121025 Bug ID: 121025 Summary: [7.0 Regression] macOS ld sysroot delegation breaks libtool Product: gcc Version: 15.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ossman at cendio dot se Target Milestone: --- Commit r228950 breaks libtool when cross compiling binaries for macOS. I assume the idea of the commit was to delegate sysroot handling to ld and have gcc ignore it. Unfortunately, libtool expects to get a list of library directories from gcc so it knows where to search for .la files. The main issue is that STANDARD_STARTFILE_PREFIX_1 and STANDARD_STARTFILE_PREFIX_2 are set to empty values. I'm not sure how that interacts with the other changes, though, so for now, we've simply reverted the entire commit.
[Bug libstdc++/121024] ranges::destroy and ranges::destroy_n do not end lifetime of trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121024 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2025-07-10 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug target/116363] gcc.c-torture/execute/conversion.c fails on H8/300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116363 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jeffrey A. Law --- This should be fixed by Jan's patch on the trunk.
[Bug cobol/120765] gcobc broken shellscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120765 --- Comment #3 from GCC Commits --- The master branch has been updated by James K. Lowden : https://gcc.gnu.org/g:3f59a1cac717f8af84e884e9ec0f6ef14e102e6e commit r16-2177-g3f59a1cac717f8af84e884e9ec0f6ef14e102e6e Author: James K. Lowden Date: Wed Jul 9 18:14:40 2025 -0400 cobol: Add PUSH and POP to CDF. Introduce cdf_directives_t class to centralize management of CDF state. Move existing CDF state variables and functions into the new class. gcc/cobol/ChangeLog: PR cobol/120765 * cdf.y: Extend grammar for new CDF syntax, relocate dictionary. * cdfval.h (cdf_dictionary): Use new CDF dictionary. * dts.h: Remove useless assignment, note incorrect behavior. * except.cc: Remove obsolete EC state. * gcobol.1: Document CDF in its own section. * genapi.cc (parser_statement_begin): Use new EC state function. (parser_file_merge): Same. (parser_check_fatal_exception): Same. * genutil.cc (get_and_check_refstart_and_reflen): Same. (get_depending_on_value_from_odo): Same. (get_data_offset): Same. (process_this_exception): Same. * lexio.cc (check_push_pop_directive): New function. (check_source_format_directive): Restrict regex search to 1 line. (cdftext::free_form_reference_format): Use new function. * parse.y: Define new CDF tokens, use new CDF state. * parse_ante.h (cdf_tokens): Use new CDF state. (redefined_token): Same. (class prog_descr_t): Remove obsolete CDF state. (class program_stack_t): Same. (current_call_convention): Same. * scan.l: Recognize new CDF tokens. * scan_post.h (is_cdf_token): Same. * symbols.h (cdf_current_tokens): Change current_call_convention to return void. * token_names.h: Regenerate. * udf/stored-char-length.cbl: Use new PUSH/POP CDF functionality. * util.cc (class cdf_directives_t): Define cdf_directives_t. (current_call_convention): Same. (cdf_current_tokens): Same. (cdf_dictionary): Same. (cdf_enabled_exceptions): Same. (cdf_push): Same. (cdf_push_call_convention): Same. (cdf_push_current_tokens): Same. (cdf_push_dictionary): Same. (cdf_push_enabled_exceptions): Same. (cdf_push_source_format): Same. (cdf_pop): Same. (cdf_pop_call_convention): Same. (cdf_pop_current_tokens): Same. (cdf_pop_dictionary): Same. (cdf_pop_enabled_exceptions): Same. (cdf_pop_source_format): Same. * util.h (cdf_push): Declare cdf_directives_t. (cdf_push_call_convention): Same. (cdf_push_current_tokens): Same. (cdf_push_dictionary): Same. (cdf_push_enabled_exceptions): Same. (cdf_push_source_format): Same. (cdf_pop): Same. (cdf_pop_call_convention): Same. (cdf_pop_current_tokens): Same. (cdf_pop_dictionary): Same. (cdf_pop_source_format): Same. (cdf_pop_enabled_exceptions): Same. libgcobol/ChangeLog: * common-defs.h (cdf_enabled_exceptions): Use new CDF state.
[Bug ipa/121023] musttail vs. IPA optimizations on the caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121023 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 61831 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61831&action=edit gcc16-pr121023.patch Untested fix.
[Bug tree-optimization/120939] vect_need_peeling_or_partial_vectors_p accesses not yet computed LOOP_VINFO_COST_MODEL_THRESHOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120939 Richard Biener changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=110571 --- Comment #1 from Richard Biener --- See also PR110571, this is a bit of a larger mess.
[Bug analyzer/106390] Support gsl::owner and/or [[gnu::owner]] attribute in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106390 --- Comment #7 from Jonathan Wakely --- Related: https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/61377
[Bug libstdc++/119754] std::uninitialized_value_construct does not begin lifetime of trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119754 --- Comment #8 from Jonathan Wakely --- (In reply to Jiang An from comment #6) > It seems that algorithms in std properly destroy trivially destructible > objects, but those in std::ranges don't. Isn't this a completely separate bug?
[Bug c++/102284] Can access object outside of its lifetime during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102284 Jonathan Wakely changed: What|Removed |Added Blocks||110367 --- Comment #9 from Jonathan Wakely --- I think this probably needs to be fixed for std::is_within_lifetime (Bug 110367) to work correctly. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110367 [Bug 110367] [C++26] Add new built-in for std::is_within_lifetime
[Bug target/121022] Suboptimal code generation for atomic_thread_fence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121022
--- Comment #1 from Yangfl ---
The motivation:
#include
#include
bool refcnt_release(atomic_int *refcnt) {
int orig = atomic_fetch_sub_explicit(refcnt, 1, memory_order_release);
if (orig > 1) {
return false;
}
// atomic_thread_fence(memory_order_acquire); // try enabling this
return true;
}
[Bug tree-optimization/120780] Missed __builtin_dynamic_object_size optimization(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780 Siddhesh Poyarekar changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #24 from Siddhesh Poyarekar --- Done.
[Bug tree-optimization/121023] musttail vs. IPA optimizations on the caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121023 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jamborm at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |15.2 --- Comment #1 from Jakub Jelinek --- I think we want to do something about this even for 15.2, people are hitting this in the wild, see e.g. https://github.com/protocolbuffers/protobuf/issues/21333#issuecomment-3051822792 (the user didn't bother to provide details, so the above is just me trying to reproduce what I think is a problem). Dunno what exactly and where though. For 15.2, perhaps it would be enough to punt on IPA optimizations which remove arguments or change their types if the function fun->has_musttail. That shouldn't affect code which doesn't use musttail attribute. Any ideas where that could be done? Dunno if we can do better for trunk, computing everything that calls.cc computes to figure out /* If this function requires more stack slots than the current function, we cannot change it into a sibling call. crtl->args.pretend_args_size is not part of the stack allocated by our caller. */ might be hard at IPA time. And yet another case I'm worried about are if we decide to use different calling convention for the fun->has_musttail functions (but not the ones which are musttail called). E.g. if caller and callee have 3 int arguments on ia32, and we decide to use regparm 1, 2 or 3 for the caller of the musttail callee but callee remains regparm 0. Or do we optimize only leaf functions? I think if caller is say regparm 2, it would use just one stack slot and if callee is regparm 0, it would use 3 and so tail call would be disallowed. Obviously, if users use regparm or have callers with fewer arguments in the source than musttail callees, it is their decision and it can fail. But what I'm talking about is cases where if we don't try to optimize stuff, it works fine, but compiler decided something that will reject the program. The disadvantage of punting is that fun->has_musttail calls will be less optimized, but perhaps users of musttail attribute made a careful decision that it is worth it.
[Bug c++/120243] [15/16 Regression] Exception rethrown from coroutine promise type unhandled_exception not caught under -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243 --- Comment #12 from Jason Merrill --- (In reply to Iain Sandoe from comment #10) > that's fine too - my plan is to back port the stack of changes made on trunk > rather than doing piecemeal - to try and avoid churn.. Yeah, backporting this patch by itself seems to regress g++.dg/coroutines/torture/exceptions-test-01-n4849-a.C so I'll leave it to you after al.
[Bug target/121025] [12/13/14/15/16 Regression] macOS ld sysroot delegation breaks libtool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121025 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.2 Summary|[7.0 Regression] macOS ld |[12/13/14/15/16 Regression] |sysroot delegation breaks |macOS ld sysroot delegation |libtool |breaks libtool
[Bug target/121022] Suboptimal code generation for atomic_thread_fence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121022 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 86019 ***
[Bug libstdc++/121026] New: ranges::uninitialized_xxx algos perform invalid optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121026
Bug ID: 121026
Summary: ranges::uninitialized_xxx algos perform invalid
optimizations
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
Firstly, the _DestroyGuard is a no-op for trivially destructible types:
template
requires destructible>
&& is_trivially_destructible_v>
struct _DestroyGuard<_Iter>
This partial specialization is a problem, because it means we don't end
lifetimes of objects created during constant evaluation. Prio to C++26 that was
OK, because the guard only has to do anything in the event of an exception,
which wasn't possible in constant expressions. For C++26 we will have constexpr
exceptions, and so should be prepared to run trivial destructors during
constant evaluation.
Maybe we want to just remove that partial specialization, or maybe we want to
keep it but give it a destructor (for C++26 only?) that only destroys objects
if ! consteval.
Secondly, ranges::uninitialized_default_construct is a no-op for trivially
default constructible types:
if constexpr (is_trivially_default_constructible_v<_ValueType>)
return ranges::next(__first, __last);
That's not correct for C++26 where the algo can be used in constant
expressions. We need to begin object lifetimes for consteval. Something like:
if constexpr (is_trivially_default_constructible_v<_ValueType>)
#if __glibcxx_raw_memory_algorithms >= 202411L
if ! consteval
#endif
{ return ranges::next(__first, __last); }
(N.B. that feature test macro isn't defined for Clang 19 because it doesn't
support constexpr placement new, P2747R2, but that means it can't support
constexpr uninitialized_default_construct anyway).
Thirdly, many of the other ranges::uninitialized_xxx algos reproduce similar
optimizations that the std::uninitialized_xxx algos used to do, e.g.
ranges::uninitialized_copy will use ranges::copy for trivially constructible
and trivially assignable types, and ranges::uninitialized_value_construct will
use ranges::fill. That is also incorrect for constexpr, because we need to
begin object lifetimes.
Also, for the non-ranges algos, the logic was rewritten for Bug 68350. We might
want to audit the ranges algos to see if similar changes are needed/wanted.
Fourthly, I don't think this ranges::uninitialized_move optimization is valid:
auto [__in, __out]
= ranges::copy_n(std::make_move_iterator(std::move(__ifirst)),
__d, __ofirst);
Not only does this fail to begin object lifetimes during constant evaluation
(as noted above), but std::move_iterator will move the values using std::move.
If the type has an overloaded iter_move findable via ADL then we should be
using that instead of std::move.
I think we can only optimize ranges::uninitialized_move for arithmetic types
(and pointers to arithmetic types?). That would enable the use of memcpy for
those types, so still seems worthwhile.
[Bug target/121022] Suboptimal code generation for atomic_thread_fence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121022 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/86019] [12/13/14/15/16 Regression] Unref implementation using atomic_thread_fence generates worse code on x86-64 in gcc 8.1 than 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86019 Andrew Pinski changed: What|Removed |Added CC||mmyangfl at gmail dot com --- Comment #13 from Andrew Pinski --- *** Bug 121022 has been marked as a duplicate of this bug. ***
[Bug libstdc++/119754] std::uninitialized_value_construct does not begin lifetime of trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119754 --- Comment #11 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #10) > However, ranges::uninitialized_value_construct has the same bug as > std::uninitialized_value_construct and wasn't fixed by my recent commit (but > I do have a fix in my local tree). I found other problems there, so that's Bug 121026 now.
[Bug libstdc++/121026] ranges::uninitialized_xxx algos perform invalid optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121026 --- Comment #1 from Jonathan Wakely --- We could also take the opportunity to look into whether any of those optimizations still buy us much performance. Is the compiler smart enough to turn the default implementation (in terms of a loop) into memcpy when needed? Presumably it can remove the entire loop from ranges::uninitialized_default_construct when it's invoking a trivial default constructor, so maybe we should just do the loop unconditionally? And presumably the compiler can turn uninitialized_value_construct into a memset when that's appropriate for the type (which the compiler knows better than the library code knows; in the library we only transform the loop to memset for 1-byte scalar types). The optimizations are useful for -O0 where the loop won't get optimized away, but do we care? If the optimizations are incorrect for constant evaluation and have subtleties with what they're allowed to do (e.g. we must use ranges::iter_move not std::move) then it would be simpler to just remove them all.
[Bug target/87949] PowerPC saves CR registers across calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug target/121007] [15/16 Regression] compiler hangs when building ffpmeg with -mcpu=power9 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007 --- Comment #13 from Vladimir Makarov --- It seems problem is in reloading an address (process_address_1). I think the existing code has enough address transformations (possible address reloads) but it chooses the wrong one. So we should modify process_address_1. Also we should fail gracefully constraining iterations in process_address as any address has just a few parts can be processed. I'll try to make a candidate patch today or tomorrow.
[Bug target/117007] Poor optimization for small vector constants needed for vector shift/rotate/mask generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117007 --- Comment #17 from Segher Boessenkool --- Hi! So, why do we not generate xxspltib where it would help. Please send a patch? Improvements will usually be to the xxspltib-generating code itself, not to the legacy code that generates the old (correct, but not ideal here) sequence!
[Bug target/121027] New: [14 Regression] ICE with BF16 and SVE at -O2 -msve-vector-bits=256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121027
Bug ID: 121027
Summary: [14 Regression] ICE with BF16 and SVE at -O2
-msve-vector-bits=256
Product: gcc
Version: 14.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails on the head of the 14 branch:
$ cat t.c
#include
typedef svbfloat16_t vls_bfloat16_t __attribute__((arm_sve_vector_bits(32 *
8)));
svbfloat16_t foo(vls_bfloat16_t a, vls_bfloat16_t b)
{
svbfloat16_t zero = svreinterpret_bf16_f32 (svdup_n_f32 (0.0f));
return svzip2_bf16(zero, svuzp1_bf16(a,b));
}
$ /work/builds/gcc14/bin/gcc -O2 -march=armv8.2-a+sve+fp16
-msve-vector-bits=256 t.c -c -S -o /dev/null
t.c: In function ‘foo’:
t.c:7:1: error: unrecognizable insn:
7 | }
| ^
(insn 15 14 16 2 (set (reg:VNx8BF 103 [ _3 ])
(unspec:VNx8BF [
(reg:VNx8BF 109)
(reg:VNx8BF 110)
] UNSPEC_IORF)) "t.c":6:10 -1
(nil))
during RTL pass: vregs
t.c:7:1: internal compiler error: in extract_insn, at recog.cc:2812
0x71bb3f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/alecop01/toolchain/src/gcc-14/gcc/rtl-error.cc:108
0x71bb73 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/alecop01/toolchain/src/gcc-14/gcc/rtl-error.cc:116
0xc8e1bb extract_insn(rtx_insn*)
/home/alecop01/toolchain/src/gcc-14/gcc/recog.cc:2812
0x9e6917 instantiate_virtual_regs_in_insn
/home/alecop01/toolchain/src/gcc-14/gcc/function.cc:1612
0x9e6917 instantiate_virtual_regs
/home/alecop01/toolchain/src/gcc-14/gcc/function.cc:1995
0x9e6917 execute
/home/alecop01/toolchain/src/gcc-14/gcc/function.cc:2042
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/121027] [14 Regression] ICE with BF16 and SVE at -O2 -msve-vector-bits=256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121027 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.4 Known to work||13.1.0, 15.1.0
[Bug target/121027] [14 Regression] ICE with BF16 and SVE at -O2 -msve-vector-bits=256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121027 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-07-10 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug target/121027] [14 Regression] ICE with BF16 and SVE at -O2 -msve-vector-bits=256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121027 Alex Coplan changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #1 from Alex Coplan --- Fixed by r15-4111-g4fd473f66faf5bd95c84fe5c0fa41be735a7c09f, looks like we should consider backporting that fix.
[Bug tree-optimization/114052] [12 Regression] Wrong code at -O2 for well-defined infinite loop since r8-5245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|12.5|13.4 Resolution|--- |FIXED Known to fail||12.5.0 --- Comment #26 from Richard Biener --- Thus fixed for GCC 13.
[Bug tree-optimization/121023] New: musttail vs. IPA optimizations on the caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121023
Bug ID: 121023
Summary: musttail vs. IPA optimizations on the caller
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
struct S { int a, b; };
[[gnu::noipa]] int
foo (struct S x, int y, int z)
{
return x.a + y + z;
}
[[gnu::noinline]] static int
bar (struct S x, int y, int z)
{
[[gnu::musttail]] return foo ((struct S) { x.a, 0 }, y, 1);
}
int
baz (int x)
{
return bar ((struct S) { 1, 2 }, x, 2) + bar ((struct S) { 2, 3 }, x + 1, 2);
}
is accepted at -O0 and -O2 on x86_64 and -O0 -m32 as well, but rejected for -O2
-m32:
pr121NNN.c: In function ‘bar.constprop.isra’:
pr121NNN.c:12:28: error: cannot tail-call: callee required more stack slots
than the caller
12 | [[gnu::musttail]] return foo ((struct S) { x.a, 0 }, y, 1);
|^
The problem is that IPA optimizations optimized bar from
int bar (struct S x, int y, int z)
to
int bar.constprop.isra (int ISRA.6, int y)
Now, on x86_64 with 6 GPRs both of (struct S, int, int) and (int, int) don't
need any stack slots and so tail call is possible regardless whether we IPA
optimize the caller or not, but if there were more than 6 arguments we could
trigger even there; and on arches which pass everything on the stack removing
arguments or replacing them with arguments of different types can be always a
problem.
[Bug tree-optimization/120780] Missed __builtin_dynamic_object_size optimization(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780 --- Comment #23 from GCC Commits --- The releases/gcc-15 branch has been updated by Siddhesh Poyarekar : https://gcc.gnu.org/g:63c4d4f59a92007c6d0f35e4d7aa1a97691306db commit r15-9948-g63c4d4f59a92007c6d0f35e4d7aa1a97691306db Author: Siddhesh Poyarekar Date: Thu Jun 26 17:46:00 2025 -0400 tree-optimization/120780: Support object size for containing objects MEM_REF cast of a subobject to its containing object has negative offsets, which objsz sees as an invalid access. Support this use case by peeking into the structure to validate that the containing object indeed contains a type of the subobject at that offset and if present, adjust the wholesize for the object to allow the negative offset. gcc/ChangeLog: PR tree-optimization/120780 * tree-object-size.cc (inner_at_offset, get_wholesize_for_memref): New functions. (addr_object_size): Call get_wholesize_for_memref. gcc/testsuite/ChangeLog: PR tree-optimization/120780 * gcc.dg/builtin-dynamic-object-size-pr120780.c: New test case. Signed-off-by: Siddhesh Poyarekar (cherry picked from commit 72e85d46472716e670cbe6e967109473b8d12d38)
[Bug tree-optimization/121023] musttail vs. IPA optimizations on the caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121023 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-07-10 Ever confirmed|0 |1 --- Comment #2 from Martin Jambor --- A big (but probably reasonably sized hammer) approach is to disable any changes to signatures of functions having a musttail call in them: --- a/gcc/ipa-fnsummary.cc +++ b/gcc/ipa-fnsummary.cc @@ -3420,7 +3420,7 @@ compute_fn_summary (struct cgraph_node *node, bool early) else info->inlinable = tree_inlinable_function_p (node->decl); - bool no_signature = false; + bool no_signature = cfun->has_musttail; /* Type attributes can use parameter indices to describe them. Special case fn spec since we can safely preserve them in modref summaries. */
[Bug c++/120955] [15/16 Regression] 50 % increase in data segment size on avr-gcc for -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955 --- Comment #9 from Georg-Johann Lay --- So when the issue goes away wihout LTO, then you can't drop -flto obviously.
[Bug target/120870] [16 regression] CPython miscompiled with preserve_none and CFLAGS="-O2 -march=znver2 -ggdb3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870 --- Comment #15 from H.J. Lu --- (In reply to Sam James from comment #10) > Created attachment 61824 [details] > ceval.i.xz > > ceval.o is broken. > > ``` > $ gcc -c -fno-strict-overflow -O2 -mavx -mtune=znver2 -std=c11 > -fvisibility=hidden -fprofile-generate /tmp/ceval.i -o Python/ceval.o > ``` $ ./configure --with-tail-call-interp CFLAGS="-O2 -march=znver2 -ggdb3" also failed to build. -fprofile-generate isn't needed.
[Bug tree-optimization/121020] [16 regression] genrecog miscompiled since r16-1624-g6deab186535a5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121020
--- Comment #8 from Sam James ---
(In reply to Pengfei Li from comment #7)
> Hi Sam, sorry about the issue. I just followed your build steps (make
> command revised) but didn't reproduce it. I also tried valgrind but it
> exited with no error. I was trying on an Intel CPU with avx512. Could you
> share more about your platform?
Sure -- I realised I made an assumption earlier with not explicitly saying you
need to build stage1 with trunk (it's not a bootstrap failure later on).
Can you try this, making sure CC and CXX point to gcc and g++ from a recent
trunk build, and also that STAGE1_* are passed in the make call?
If that's not enough, I'll get a tarball later of the needed preprocessed
sources to build a bad binary.
```
$ mkdir ~/bugs/gcc && cd ~/bugs/gcc
$ export CC=/path/to/gcc-trunk CXX=/path/to/g++-trunk
$ ~/git/gcc/configure --enable-checking=release
$ make -j$(nproc) -l$(nproc) STAGE1_C{,XX}FLAGS="-O3 -march=znver2 -ggdb3"
$ cd gcc
$ valgrind -q build/genrecog ~/git/gcc/gcc/common.md
~/git/gcc/gcc/config/i386/i386.md insn-conditions.md -Hinsn-recog.h
-Otmp-recog-1.cc -Otmp-rec
og-2.cc -Otmp-recog-3.cc -Otmp-recog-4.cc -Otmp-recog-5.cc -Otmp-recog-6.cc
-Otmp-recog-7.cc -Otmp-recog-8.cc -Otmp-recog-9.cc -Otmp-recog-10.cc
```
[Bug libstdc++/121026] ranges::uninitialized_xxx algos perform invalid optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121026
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> Fourthly, I don't think this ranges::uninitialized_move optimization is
> valid:
>
> auto [__in, __out]
> = ranges::copy_n(std::make_move_iterator(std::move(__ifirst)),
> __d, __ofirst);
>
> Not only does this fail to begin object lifetimes during constant evaluation
> (as noted above), but std::move_iterator will move the values using
> std::move. If the type has an overloaded iter_move findable via ADL then we
> should be using that instead of std::move.
>
> I think we can only optimize ranges::uninitialized_move for arithmetic types
> (and pointers to arithmetic types?). That would enable the use of memcpy for
> those types, so still seems worthwhile.
We could reuse the concept used by ranges::iter_move:
if constexpr (!ranges::__imove::__adl_imove>)
{
auto [__in, __out]
=
ranges::uninitialized_copy(std::make_move_iterator(std::move(__ifirst)),
__ilast, __ofirst, __olast);
return {std::move(__in).base(), __out};
}
else
[Bug middle-end/121000] __builtin_dynamic_object_size should work for FAM with VLA element when annotated with counted_by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000 --- Comment #11 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #9) I just sent out the patches to gcc-patches alias to fix this bug and also reduce the # of arguments from 6 to 4. I splited the changes into 2 separate patches in order to make each change single purpose. could you please review and approve the patchs if there is no issue there? thanks.
[Bug target/120986] ICE when expanding svdot_lane_fpm intrinsic with compile time know FPMR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120986
--- Comment #4 from Alex Coplan ---
I also get an unrecognisable insn ICE when compiling a variant of this testcase
where the FPMR has a compile-time unknown value:
$ cat t.c
#pragma GCC aarch64 "arm_sve.h"
svfloat16_t foo(svfloat16_t a, svmfloat8_t b, svmfloat8_t c, unsigned long fpm)
{
return svdot_lane_fpm (a, b, c, 0, fpm);
}
$ ./xgcc -B . -c t.c -O2 -S -o - -march=armv8.2-a+sve2+fp8dot2
.arch armv8.2-a+crc+sve2+fp8dot2
.file "t.c"
.text
t.c: In function ‘foo’:
t.c:5:1: error: unrecognizable insn:
5 | }
| ^
(insn 10 9 14 2 (set (reg:VNx8HF 101 [ ])
(unspec:VNx8HF [
(reg/v:VNx8HF 102 [ a ])
(reg/v:VNx16QI 103 [ b ])
(reg/v:VNx16QI 104 [ c ])
(const_int 0 [0])
(reg:DI 84 fpmr)
] UNSPEC_DOT_LANE_FP8)) "t.c":4:10 -1
(nil))
during RTL pass: vregs
t.c:5:1: internal compiler error: in extract_insn, at recog.cc:2882
0x36f0265 internal_error(char const*, ...)
/fast/trunk/src/gcc/gcc/diagnostic-global-context.cc:517
0x36ade5c fancy_abort(char const*, int, char const*)
/fast/trunk/src/gcc/gcc/diagnostic.cc:1810
0x1984d6c _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/fast/trunk/src/gcc/gcc/rtl-error.cc:108
0x1984db1 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/fast/trunk/src/gcc/gcc/rtl-error.cc:116
0x1931a33 extract_insn(rtx_insn*)
/fast/trunk/src/gcc/gcc/recog.cc:2882
0x146bbc0 instantiate_virtual_regs_in_insn
/fast/trunk/src/gcc/gcc/function.cc:1609
0x146d23c instantiate_virtual_regs
/fast/trunk/src/gcc/gcc/function.cc:1985
0x146d320 execute
/fast/trunk/src/gcc/gcc/function.cc:2032
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug rtl-optimization/110093] [12/13/14 Regression][avr] Move frenzy leading to code bloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093 Georg-Johann Lay changed: What|Removed |Added Summary|[12/13/14/15/16 |[12/13/14 Regression][avr] |Regression][avr] Move |Move frenzy leading to code |frenzy leading to code |bloat |bloat | --- Comment #7 from Georg-Johann Lay --- As it seems, this PR is no more present in v15.1 and trunk.
[Bug target/120999] Assembler warning about MOVPRFX generation for NBSL instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120999 --- Comment #2 from GCC Commits --- The master branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:b7bd72ce71df5266e7a7039da318e49862389a72 commit r16-2165-gb7bd72ce71df5266e7a7039da318e49862389a72 Author: Kyrylo Tkachov Date: Wed Jul 9 10:04:01 2025 -0700 aarch64: PR target/120999: Adjust operands for movprfx alternative of NBSL implementation of NOR While the SVE2 NBSL instruction accepts MOVPRFX to add more flexibility due to its tied operands, the destination of the movprfx cannot be also a source operand. But the offending pattern in aarch64-sve2.md tries to do exactly that for the "=?&w,w,w" alternative and gas warns for the attached testcase. This patch adjusts that alternative to avoid taking operand 0 as an input in the NBSL again. So for the testcase in the patch we now generate: nor_z: movprfx z0, z1 nbslz0.d, z0.d, z2.d, z1.d ret instead of the previous: nor_z: movprfx z0, z1 nbslz0.d, z0.d, z2.d, z0.d ret which generated a gas warning. Bootstrapped and tested on aarch64-none-linux-gnu. Signed-off-by: Kyrylo Tkachov gcc/ PR target/120999 * config/aarch64/aarch64-sve2.md (*aarch64_sve2_nor): Adjust movprfx alternative. gcc/testsuite/ PR target/120999 * gcc.target/aarch64/sve2/pr120999.c: New test.
[Bug libstdc++/119754] std::uninitialized_value_construct does not begin lifetime of trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119754
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> #include
> #include
>
> consteval bool f(int n)
> {
> int* p = std::allocator().allocate(n);
> std::uninitialized_value_construct(p, p+n);
> std::allocator().deallocate(p, n);
> return true;
> }
>
> static_assert(f(10));
>
>
> With -std=c++26 GCC accepts this, but Clang doesn't:
>
> ef.cc:12:15: error: static assertion expression is not an integral constant
> expression
>12 | static_assert(f(10));
> | ^
> /home/jwakely/gcc/15/lib/gcc/x86_64-pc-linux-gnu/15.0.1/../../../../include/
> c++/15.0.1/bits/stl_algobase.h:925:11: note: assignment to object outside
> its lifetime is not allowed in a constant expression
> 925 | *__first = __val;
> | ~^~~
Fixed on trunk by r16-2154-g82d2d12da93b5a
[Bug middle-end/120987] [14/15/16 regression] gdb build with lto triggers use after free since r14-5831-gaae723d360ca26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #10 from Tom de Vries ---
(In reply to Tom de Vries from comment #4)
> and then rethrown:
> ...
> if (file_exception.reason < 0)
> throw_exception (std::move (file_exception));
> ...
>
> The gdb_exception class contains a message member:
> ...
> std::shared_ptr message;
> ...
> and the std::move should leave file_exception.message in a "valid but
> unspecified state" but gcc seems optimize that away.
Let's look at this in a bit more detail, at "-O0 -g".
We set a breakpoint at the line containing throw_exception, and run to it.
At that point, message is:
...
(gdb) p file_exception.message
$2 = std::shared_ptr, s
td::allocator >> (use count 1, weak count 0) = {get() = 0x1371640}
...
We step into throw_exception, until here:
...
188 else if (exception.reason == RETURN_ERROR)
> 189 throw gdb_exception_error (std::move (exception));
...
Then step into gdb_exception_error constructor:
...
280 explicit gdb_exception_error (gdb_exception &&ex) noexcept
> 281 : gdb_exception (std::move (ex))
...
Then into gdb_exception constructor:
...
> 144 explicit gdb_exception (gdb_exception &&other) noexcept = default
...
Then into shared_ptr constructor:
...
358 shared_ptr(shared_ptr&& __r) noexcept
> 359 : __shared_ptr<_Tp>(std::move(__r)) { }
...
Then into __shared_ptr constructor:
...
│ 1532 __shared_ptr(__shared_ptr&& __r) noexcept│
│ > 1533 : _M_ptr(__r._M_ptr), _M_refcount() │
│ 1534 {│
│ 1535 _M_refcount._M_swap(__r._M_refcount); │
│ 1536 __r._M_ptr = nullptr; │
│ 1537 }│
...
When entering this function, file_exception.message still has the same value.
After the swap, we have:
...
(gdb) p file_exception.message
$10 = std::shared_ptr,
std::allocator >> (empty) = {get() = 0x1371640}
(gdb)
...
and after the nullptr assignment we have:
...
gdb) p file_exception.message
$12 = std::shared_ptr,
std::allocator >> (empty) = {get() = 0x0}
...
Now with "-O2 -flto=auto".
We start out with:
...
(gdb) p file_exception.message
$2 = std::shared_ptr,
std::allocator >> (use count 1, weak count 0) = {get() = }
...
We step into throw_exception, then gdb_exception_error constructor, then
gdb_exception constructor, then shared_ptr constructor, then __shared_ptr
constructor. The code is scattered by lto, so I stepi through it.
Finally, we reach __cxa_throw.
At that point, file_exception.message is still the same (though the optimized
out part may have changed):
...
(gdb) p file_exception.message
$21 = std::shared_ptr,
std::allocator >> (use count 1, weak count 0) = {
get() = }
...
but the use count should have been 0 at that point.
Looking at the first argument of __cxa_throw, the construction of the exception
object went ok:
...
(gdb) p /x $rdi
$23 = 0xe145b0
(gdb) p ((gdb_exception *)0xe145b0)->message
$24 = std::shared_ptr,
std::allocator >> (use count 1, weak count 0) = {get() = 0xe14620}
(gdb) p *((gdb_exception *)0xe145b0)->message
$25 = "No symbol table is loaded. Use the \"file\" command."
...
[Bug tree-optimization/121020] [16 regression] genrecog miscompiled since r16-1624-g6deab186535a5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121020 --- Comment #7 from Pengfei Li --- Hi Sam, sorry about the issue. I just followed your build steps (make command revised) but didn't reproduce it. I also tried valgrind but it exited with no error. I was trying on an Intel CPU with avx512. Could you share more about your platform?
[Bug middle-end/114070] [12 regression] ICE when building git-2.43.2 with -mcpu=niagara4 -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114070 Richard Biener changed: What|Removed |Added Known to fail||12.5.0 Target Milestone|12.5|13.3 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #15 from Richard Biener --- Fixed for 13.3
[Bug libstdc++/121024] New: ranges::destroy and ranges::destroy_n do not end lifetime of trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121024
Bug ID: 121024
Summary: ranges::destroy and ranges::destroy_n do not end
lifetime of trivial types
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: daniel.kruegler at googlemail dot com, de34 at live dot cn,
tkaminsk at gcc dot gnu.org, unassigned at gcc dot gnu.org,
webrown.cpp at gmail dot com
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #119754 comment 6 +++
Consider this example (https://godbolt.org/z/dGGE6o5qY):
```
#include
using namespace std;
template
struct require_valid_constant;
template
constexpr int consteval_validate_destruction(Fn op) {
struct S {
int n;
};
S arr[1]{{42}};
op(arr);
return arr[0].n;
}
template
constexpr bool CanWellDefinedlyAccessAfterOperation =
requires { typename
require_valid_constant; };
static_assert(CanWellDefinedlyAccessAfterOperation<[](auto&) {}>);
static_assert(!CanWellDefinedlyAccessAfterOperation<[](auto& arr) { destroy(arr
+ 0, arr + 1); }>);
static_assert(!CanWellDefinedlyAccessAfterOperation<[](auto& arr) {
destroy_at(arr + 0); }>);
static_assert(!CanWellDefinedlyAccessAfterOperation<[](auto& arr) {
destroy_at(&arr); }>);
static_assert(!CanWellDefinedlyAccessAfterOperation<[](auto& arr) {
destroy_n(arr + 0, 1); }>);
static_assert(!CanWellDefinedlyAccessAfterOperation<[](auto& arr) {
ranges::destroy(arr + 0, arr + 1); }>);
static_assert(!CanWellDefinedlyAccessAfterOperation<[](auto& arr) {
ranges::destroy(arr); }>);
static_assert(!CanWellDefinedlyAccessAfterOperation<[](auto& arr) {
ranges::destroy_at(arr + 0); }>);
static_assert(!CanWellDefinedlyAccessAfterOperation<[](auto& arr) {
ranges::destroy_at(&arr); }>);
static_assert(!CanWellDefinedlyAccessAfterOperation<[](auto& arr) {
ranges::destroy_n(arr + 0, 1); }>);
```
It seems that algorithms in std properly destroy trivially destructible
objects, but those in std::ranges don't.
Although the difference is only observable by Clang due to Bug 102284.
[Bug libstdc++/119754] std::uninitialized_value_construct does not begin lifetime of trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119754 --- Comment #9 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #8) > (In reply to Jiang An from comment #6) > > It seems that algorithms in std properly destroy trivially destructible > > objects, but those in std::ranges don't. > > Isn't this a completely separate bug? The ranges::destroy bug is now Bug 121024
[Bug libstdc++/119754] std::uninitialized_value_construct does not begin lifetime of trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119754 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #10 from Jonathan Wakely --- However, ranges::uninitialized_value_construct has the same bug as std::uninitialized_value_construct and wasn't fixed by my recent commit (but I do have a fix in my local tree).
[Bug c++/121008] [16 Regression] Error on 'this' inside noexcept specifier of lambda capturing 'this' inside noexcept specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121008 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jason Merrill --- Fixed.
[Bug tree-optimization/119876] suboptimal code for avx512 conditional move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119876 --- Comment #5 from Jan Hubicka --- I think I made the testcase while working on something else that I forgot, sorry :)
[Bug c++/121012] [16 Regression] Error on lambda with auto parameter as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121012 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed.
[Bug target/120986] ICE when expanding svdot_lane_fpm intrinsic with compile time know FPMR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120986
Alex Coplan changed:
What|Removed |Added
Ever confirmed|0 |1
CC||acoplan at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2025-07-10
--- Comment #3 from Alex Coplan ---
Confirmed. Here's a reproducer that works with just a cc1 and the stack trace:
$ cat t.c
#pragma GCC aarch64 "arm_sve.h"
svfloat16_t test (svfloat16_t a, svmfloat8_t b, svmfloat8_t c)
{
return svdot_lane_fpm (a, b, c, 0, 0);
}
$ ./xgcc -B . -c t.c -O2 -S -o - -march=armv8.2-a+sve2+fp8dot2
.arch armv8.2-a+crc+sve2+fp8dot2
.file "t.c"
.text
during RTL pass: expand
t.c: In function ‘test’:
t.c:5:12: internal compiler error: in expand, at
config/aarch64/aarch64-sve-builtins.cc:4592
5 | return svdot_lane_fpm (a, b, c, 0, 0);
|^~
0x36f0265 internal_error(char const*, ...)
/fast/trunk/src/gcc/gcc/diagnostic-global-context.cc:517
0x36ade5c fancy_abort(char const*, int, char const*)
/fast/trunk/src/gcc/gcc/diagnostic.cc:1810
0x21c7890 aarch64_sve::function_expander::expand()
/fast/trunk/src/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:4592
0x21ca099 aarch64_sve::expand_builtin(unsigned int, tree_node*, rtx_def*)
/fast/trunk/src/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:4967
0x1fd6959 aarch64_expand_builtin
/fast/trunk/src/gcc/gcc/config/aarch64/aarch64.cc:16254
0x11b3047 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/fast/trunk/src/gcc/gcc/builtins.cc:7839
0x13df62f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/fast/trunk/src/gcc/gcc/expr.cc:12535
0x13d00ba expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/fast/trunk/src/gcc/gcc/expr.cc:9523
0x13c41e3 store_expr(tree_node*, rtx_def*, int, bool, bool)
/fast/trunk/src/gcc/gcc/expr.cc:6762
0x13c27f6 expand_assignment(tree_node*, tree_node*, bool)
/fast/trunk/src/gcc/gcc/expr.cc:6483
0x11fb580 expand_call_stmt
/fast/trunk/src/gcc/gcc/cfgexpand.cc:3202
0x11ff570 expand_gimple_stmt_1
/fast/trunk/src/gcc/gcc/cfgexpand.cc:4276
0x11ffba5 expand_gimple_stmt
/fast/trunk/src/gcc/gcc/cfgexpand.cc:4423
0x11ffce6 expand_gimple_tailcall
/fast/trunk/src/gcc/gcc/cfgexpand.cc:4470
0x1208be9 expand_gimple_basic_block
/fast/trunk/src/gcc/gcc/cfgexpand.cc:6512
0x120b3a9 execute
/fast/trunk/src/gcc/gcc/cfgexpand.cc:7286
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/119876] suboptimal code for avx512 conditional move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119876 --- Comment #6 from Jan Hubicka --- Aha, I was looking into scalar-to-vector improvements promoting scalar integer + 1 to vector on AMD CPUs.
[Bug target/120977] [16 Regression] ICE on Cortex-M23/M33/M55/M85 with -mcmse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120977 Christophe Lyon changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Christophe Lyon --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689230.html
[Bug target/121007] [15/16 Regression] compiler hangs when building ffpmeg with -mcpu=power9 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007 --- Comment #14 from Segher Boessenkool --- Thanks! If there is anything we (Power people) can do, please let us know!
[Bug target/121015] [16 regression] ICE when building blender for x86_64 with -O3 -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121015 H.J. Lu changed: What|Removed |Added Attachment #61829|0 |1 is obsolete|| --- Comment #6 from H.J. Lu --- Created attachment 61830 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61830&action=edit A new patch
[Bug c++/121021] Move -Wuninitialized from -Wextra to -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121021 --- Comment #6 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #3) > Hmm, I do think there is a documentation issue though it says -Wextra > enables -Wuninitialized but it is -Wall that does. Right, -Wextra clearly documents that it enables it: -Wextra This enables some extra warning flags that are not enabled by -Wall. [...] [...] -Wuninitialized [...] That's why I told the reporter that it's not in -Wall which turns out to have been wrong.
[Bug c++/121021] Move -Wuninitialized from -Wextra to -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121021
--- Comment #7 from Jonathan Wakely ---
(In reply to Žarko Asen from comment #5)
> in my case (C++ 20) -Wunitialized was not enabled by -Wall therefore a
> critical bug slip through:
>
> const uint32_t x = x + 1; // where is a novel variable in the local and
> global scope
>
> This should have been caught by -Wall and it wasn't. G++14.2.0 C++20 -Wall
> -pedantic -Werror
You haven't shown a testcase where you don't get that warning.
As I said by email, there's no warning for a global variable because it's
zero-initialized (although Clang still warns and I think that would be useful
for GCC too). At local scope GCC does warn e.g.
#include
int f()
{
const uint32_t x1 = x1 + 1;
return 0;
}
self.cc: In function ‘f’:
self.cc:5:18: warning: ‘x1’ is used uninitialized [-Wuninitialized]
5 | const uint32_t x1 = x1 + 1;
| ^~
self.cc:5:18: note: ‘x1’ was declared here
5 | const uint32_t x1 = x1 + 1;
| ^~
[Bug libstdc++/121026] ranges::uninitialized_xxx algos perform invalid optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121026 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-07-11 Ever confirmed|0 |1 CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- confirmed (In reply to Jonathan Wakely from comment #1) > The optimizations are useful for -O0 where the loop won't get optimized > away, but do we care? If the optimizations are incorrect for constant > evaluation and have subtleties with what they're allowed to do (e.g. we must > use ranges::iter_move not std::move) then it would be simpler to just remove > them all. Makes sense for GCC 16, but I guess on release branches we would want to fix the optimizations instead of removing them.
[Bug tree-optimization/121014] vectorizer uses RDIV_EXPR for integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121014 --- Comment #4 from rguenther at suse dot de --- On Thu, 10 Jul 2025, rdapp at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121014 > > Robin Dapp changed: > >What|Removed |Added > > Resolution|--- |FIXED > Status|NEW |RESOLVED > CC||rdapp at gcc dot gnu.org > > --- Comment #3 from Robin Dapp --- > Fixed on trunk. I don't suppose we want to backport this as it's pretty > harmless (all div variants expand to u/sdiv anyway)? If there are no problems reported from the fix I'd say we want to backport just the s/RDIV_EXRP/EXACT_DIV_EXPR/ change
[Bug target/121027] [14 Regression] ICE with BF16 and SVE at -O2 -msve-vector-bits=256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121027 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug cobol/120787] FR: EXHIBIT + EXHIBIT named support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120787 --- Comment #4 from Simon Sobisch --- > If CHANGED is not important, we can emit a not-implemented warning and always > print, changed or not. This is what GnuCOBOL does, leading to: * existing code compiles * code does run, it "just" creates too much output While there _is_ the option that some monitoring checks for the "changed" part in its output and "what is possible is done somewhere", this is so unlikely that we decided to go with 90% until someone says he needs the runtime support for the missing 10% as well.
[Bug target/120870] [16 regression] CPython miscompiled with preserve_none and CFLAGS="-O2 -march=znver2 -ggdb3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870 --- Comment #16 from Sam James --- (In reply to H.J. Lu from comment #15) > also failed to build. -fprofile-generate isn't needed. Ugh. Not sure why I keep making mistakes on this one.
[Bug c++/110338] Implement C++26 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338 Bug 110338 depends on bug 117785, which changed state. Bug 117785 Summary: [C++26] P3068R5 - constexpr exceptions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug cobol/120621] COBOL isn't built with STRICT_WARN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120621 --- Comment #13 from James K. Lowden --- Please apply https://gcc.gnu.org/pipermail/gcc-patches/2025-June/687385.html, and thank you for the work.
[Bug cobol/120779] HIGH-VALUE / LOW-VALUE not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120779 James K. Lowden changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from James K. Lowden --- This in fact was a corner-case scanner problem, fixed as part of a large patch on June 30. The specific example is fixed, for sure, not that parsing is ever perfect. Closing with a hint of optimism.
[Bug c++/120628] GCC emits incorrect warnings/errors for identifiers "final" and "override" in C++98 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120628
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8f063b40e5b8f23cb89fee21afaa71deedbdf2aa
commit r16-2185-g8f063b40e5b8f23cb89fee21afaa71deedbdf2aa
Author: Jakub Jelinek
Date: Thu Jul 10 23:47:42 2025 +0200
c++: Fix up final handling in C++98 [PR120628]
The following patch is on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686210.html
patch which stopped treating override as conditional keyword in
class properties.
This PR mentions another problem; we emit a bogus warning on code like
struct C {}; struct C final = {};
in C++98. In this case we parse final as conditional keyword in C++
(including pedwarn) but the caller then immediately aborts the tentative
parse because it isn't followed by { nor (in some cases) : .
I think we certainly shouldn't pedwarn on it, but I think we even shouldn't
warn for it say for -Wc++11-compat, because we don't actually treat the
identifier as conditional keyword even in C++11 and later.
The patch only does this if final is the only class property conditional
keyword, if one uses
struct S __final final __final = {};
one gets the warning and duplicate diagnostics and later parsing errors.
2025-07-10 Jakub Jelinek
PR c++/120628
* parser.cc (cp_parser_elaborated_type_specifier): Use
cp_parser_nth_token_starts_class_definition_p with extra argument 1
instead of cp_parser_next_token_starts_class_definition_p.
(cp_parser_class_property_specifier_seq_opt): For final conditional
keyword in C++98 check if the token after it isn't
cp_parser_nth_token_starts_class_definition_p nor CPP_NAME and in
that case break without consuming it nor warning.
(cp_parser_class_head): Use
cp_parser_nth_token_starts_class_definition_p with extra argument 1
instead of cp_parser_next_token_starts_class_definition_p.
(cp_parser_next_token_starts_class_definition_p): Renamed to ...
(cp_parser_nth_token_starts_class_definition_p): ... this. Add N
argument. Use cp_lexer_peek_nth_token instead of
cp_lexer_peek_token.
* g++.dg/cpp0x/final1.C: New test.
* g++.dg/cpp0x/final2.C: New test.
* g++.dg/cpp0x/override6.C: New test.
[Bug cobol/120767] cdf-includes: needs to work in any source format (use of floating comment indicators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120767 James K. Lowden changed: What|Removed |Added CC||jklowden at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2025-07-10 Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org --- Comment #1 from James K. Lowden --- Hopefully this PR is resolved by a $10 solution to a $0.10 problem, namely 3f59a1cac717f8af84e884e9ec0f6ef14e102e6e, which adds >>PUSH and >>POP. The format-detection heuristic can still be fooled by -include and, worse, the included file might cause the heuristic to guess the format from the included file, not the main one. This update specifically begins the included file with >>PUSH SOURCE FORMAT and ends with >>POP SOURCE FORMAT. The heuristic might still go awry; I made no effort to restore the state to "indeterminate". But if the command-line uses, say, -ffree-form -include udf/stored-char-length.cbl the result should be 1. free format is set before any file is read 2. udf/stored-char-length.cbl - pushes free format - sets fixed format - processes the file - pops back to free format 3. the first file on the command line is then processed as free format. If that doesn't work, we have more work to do. In fact, we always have more work to do. Let me know. :-)
[Bug c++/117785] [C++26] P3068R5 - constexpr exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |16.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #24 from Jakub Jelinek --- Implemented for GCC 16.
[Bug c++/117785] [C++26] P3068R5 - constexpr exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785 --- Comment #25 from Jakub Jelinek --- (In reply to Hana Dusíková from comment #1) > It's not part of the wording as CWG told me to take it out. But it's very > useful when an exception is not caught to call it's `.what()` and print > resulting message as part of the error. If there is no `.what()` available, > just print it structurally. In the end this is done only for classes derived from std::exception, to match e.g. the verbose terminate handler at runtime.
[Bug target/120870] [16 regression] CPython miscompiled with preserve_none and CFLAGS="-O2 -march=znver2 -ggdb3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870 --- Comment #17 from H.J. Lu --- Created attachment 61837 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61837&action=edit A patch Please try this. No idea why it works for me.
[Bug target/121028] [15/16 Regression] __arm_streaming_compatible vs -fstack-protector-strong; emits smstop but should have changed the arch around it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121028
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Summary|[15/16 Regression] |[15/16 Regression]
|arm::streaming_compatible |__arm_streaming_compatible
|vs |vs
|-fstack-protector-strong; |-fstack-protector-strong;
|emits smstop|emits smstop but should
||have changed the arch
||around it
Last reconfirmed||2025-07-10
--- Comment #1 from Andrew Pinski ---
Confirmed.
Reduced:
```
#include
void func(void) __arm_streaming_compatible
{
char a[1024];
}
```
[Bug target/121028] [15/16 Regression] Some tests added in r15-5785-gdfa78681851 fail with -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121028 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.2 Summary|Some tests added in |[15/16 Regression] Some |r15-5785-gdfa78681851 fail |tests added in |with|r15-5785-gdfa78681851 fail |-fstack-protector-strong|with ||-fstack-protector-strong
[Bug c++/117785] [C++26] P3068R5 - constexpr exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #23 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:baaee10123db6cf896283175b345d535b225defb
commit r16-2183-gbaaee10123db6cf896283175b345d535b225defb
Author: Jakub Jelinek
Date: Thu Jul 10 23:26:15 2025 +0200
c++, libstdc++: Implement C++26 P3068R5 - constexpr exceptions [PR117785]
The following patch implements the C++26 P3068R5 - constexpr exceptions
paper.
As the IL cxx_eval_constant* functions process already contains the low
level calls like __cxa_{allocate,free}_exception, __cxa_{,re}throw etc.,
the patch just makes 10 extern "C" __cxa_* functions magic builtins which
during constant evaluation pretend to be constexpr even when not declared
so and handle them directly, plus does the same for 3 std namespace
functions - std::uncaught_exceptions, std::current_exception and
std::rethrow_exception and adds one new FE builtin -
__builtin_eh_ptr_adjust_ref which the library can use instead of the
_M_addref and _M_release out of line methods (this one instead of
recognizing _M_* as magic too because those are clearly specific to
libstdc++ and e.g. libc++ could use something else).
The patch uses magic VAR_DECLs with heap_{uninit_,,deleted_}identifier
DECL_NAME like for operator new/delete for objects allocated with
__cxa_allocate_exception, just sets their DECL_LANG_SPECIFIC so that
we can track their reference count as well (with std::exception_ptr
the same exception object can be referenced multiple times and we want
to destruct and free only when it reaches zero refcount).
For uncaught exceptions being propagated, the patch uses new kind of
*jump_target, which is that magic VAR_DECL described above.
The largest change in the patch is making jump_target argument non-optional
in cxa_eval_constant_exception and all functions it calls that need it.
This is because exceptions can be thrown from pretty much everywhere, e.g.
binary expression can throw in either operand. And the patch also adds
if (*jump_target) return NULL_TREE; or similar in many spots, so that we
don't crash because cxx_eval_constant_expression returned NULL_TREE
somewhere before actually trying to use it and so that we don't uselessly
dive into other operands etc.
Note, with statement expressions actually this was something we just didn't
handle correctly before, one can validly have:
a = ({ if (x) return 42; 12; }) + b;
or in the other operand, or break/continue instead of return if it is
somewhere in a loop/switch; and it isn't ok to branch from one operand to
another one through some kind of goto.
On the potential_constant_expression_1 side, important change was to
set *jump_target conservatively on calls that could throw for C++26 (the
patch uses magic void_node for potential_constant_expression* instead of
VAR_DECL, so that we don't have to create new VAR_DECLs there uselessly).
Without that change, several methods in libstdc++ wouldn't work correctly.
I'm not sure what exactly potential_constant_expression_1 maps to in the
C++26 standard wording now and whether doing that is ok, because basically
after the first call to non-noexcept function it stops checking stuff.
And, in some spots where I know potential_constant_expression_1 didn't
check some subexpressions (e.g. the EH only cleanups or TRY_BLOCK handlers)
I've added *potential_constant_expression* calls during cxx_eval_constant*,
not sure if I need to do that because potential_constant_expression_1 is
very conservative and just doesn't recurse on subexpressions in many cases.
2025-07-10 Jakub Jelinek
PR c++/117785
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__cpp_constexpr_exceptions=202411L for C++26.
gcc/cp/
* constexpr.cc: Implement C++26 P3068R5 - constexpr exceptions.
(class constexpr_global_ctx): Add caught_exceptions and
uncaught_exceptions members.
(constexpr_global_ctx::constexpr_global_ctx): Initialize
uncaught_exceptions.
(returns, breaks, continues, switches): Move earlier.
(throws): New function.
(exception_what_str, diagnose_std_terminate,
diagnose_uncaught_exception): New functions.
(enum cxa_builtin): New type.
(cxx_cxa_builtin_fn_p, cxx_eval_cxa_builtin_fn): New functions.
(cxx_eval_builtin_function_call): Add jump_target argument. Call
cxx_eval_cxa_builtin_fn for __builtin_eh_ptr_adjust_ref. Adjust
cxx_eval_constant_expression calls, if it results in jmp_target,
set *jump_target to it and return.
(cxx_bind_parameters_in_call): Add jump_target argument. Pass
it through to
[Bug c++/120569] Valid C++14 (or C++11/C++98) incorrectly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120569
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:bcb51fe0e26bed7e2c44c4822ca6dec135ba61f3
commit r16-2184-gbcb51fe0e26bed7e2c44c4822ca6dec135ba61f3
Author: Jakub Jelinek
Date: Thu Jul 10 23:41:56 2025 +0200
c++: Don't incorrectly reject override after class head name [PR120569]
While the
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2786r13.html#c03-compatibility-changes-for-annex-c-diff.cpp03.dcl.dcl
hunk dropped because
struct C {}; struct C final {};
is actually not valid C++98 (which didn't have list initialization), we
actually also reject
struct D {}; struct D override {};
and that IMHO is valid all the way from C++11 onwards.
Especially in the light of P2786R13 adding new contextual keywords, I think
it is better to use a separate routine for parsing the
class-virt-specifier-seq (in C++11, there was export next to final),
class-virt-specifier (in C++14 to C++23) and
class-property-specifier-seq (in C++26) instead of using the same function
for virt-specifier-seq and class-property-specifier-seq.
2025-07-10 Jakub Jelinek
PR c++/120569
* parser.cc (cp_parser_class_property_specifier_seq_opt): New
function.
(cp_parser_class_head): Use it instead of
cp_parser_property_specifier_seq_opt. Don't diagnose
VIRT_SPEC_OVERRIDE here. Formatting fix.
* g++.dg/cpp0x/override2.C: Expect different diagnostics with
override or duplicate final.
* g++.dg/cpp0x/override5.C: New test.
* g++.dg/cpp0x/duplicate1.C: Expect different diagnostics with
duplicate final.
[Bug middle-end/121032] New: ICE on x86_64-linux-gnu: 'verify_gimple' failed during GIMPLE pass: lower with vector_size and amp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121032
Bug ID: 121032
Summary: ICE on x86_64-linux-gnu: 'verify_gimple' failed during
GIMPLE pass: lower with vector_size and amp
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jiangchangwu at smail dot nju.edu.cn
Target Milestone: ---
Compiler Explorer: https://gcc.godbolt.org/z/Tb3d4ccje
***
gcc version:
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/software/gcc-trunk --enable-coverage
--disable-werror --enable-checking=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250613 (experimental) (GCC)
***
Program:
$ cat mutant.c
void a() {
register
__attribute__((__vector_size__(4 * sizeof(float float b asm("xmm4");
#pragma omp parallel for
for (int c = 0; c < 4; c++)
c < b[c];
}
***
Command Lines:
$ gcc -fopenmp mutant.c
mutant.c: In function 'a':
mutant.c:6:10: error: 'var_decl' as base where non-register is required
6 | c < b[c];
| ~^~~
b
D.3109 = VIEW_CONVERT_EXPR(b)[c];
during GIMPLE pass: lower
mutant.c:6:10: internal compiler error: 'verify_gimple' failed
0x5554b38 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x221044e verify_gimple_in_seq(gimple*, bool)
../../gcc/gcc/tree-cfg.cc:5350
0x1e90b55 execute_function_todo
../../gcc/gcc/passes.cc:2105
0x1e8e9f8 do_per_function
../../gcc/gcc/passes.cc:1703
0x1e90f6b execute_todo
../../gcc/gcc/passes.cc:2155
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug middle-end/121000] __builtin_dynamic_object_size should work for FAM with VLA element when annotated with counted_by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000 --- Comment #13 from qinzhao at gcc dot gnu.org --- fixed in gcc16. should be backported to GCC15 as well.
[Bug fortran/120958] tree-sra "miscompiles" asynchronous MPI (mpi_irecv) in Fortran 77 because of wrong fnspec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120958 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #12 from Mikael Morin --- (In reply to anlauf from comment #10) > JTFR: I can confirm the failure with 14.3+ here at -O1 and higher. > > The problem vanishes for: > > - adding the ASYNCHRONOUS attribute to norm_temp2 This appears to be the correct fix, but we should try to find something else that doesn't requires to update all code using mpi. I think in the mpi_f08 module the arguments are declared with the asynchronous attribute, so we can catch that to amend the fnspec. For mpif.h we can amend gfc_get_formal_from_actual_arglist to guess the asynchronous attribute for some arguments of the mpi_* functions, and then it's as in the mpi_f08 module case. For the mpi module I don't know. There is an explicit interface, so we don't use gfc_get_formal_from_actual_arglist, but there is no asynchronous attribute as far as I know.
[Bug bootstrap/119430] profiledbootstrap fails on armv7a-unknown-linux-gnueabhif (crashes in elists__append_elmt during stagefeedback)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119430
--- Comment #18 from Sam James ---
(In reply to Alexandre Oliva from comment #17)
> FWIW, with the candidate fix, and
> --with-specs='%{!mno-long-calls:-mlong-calls}
> %{!fno-function-sections:-ffunction-sections}'
TIL you can do that.
> on top of the earlier
> configure and make flags, I've completed a profiledbootstrap successfully.
I'll give it a whirl now. Thank you very much Alex.
[Bug bootstrap/119430] profiledbootstrap fails on armv7a-unknown-linux-gnueabhif (crashes in elists__append_elmt during stagefeedback)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119430 --- Comment #19 from Alexandre Oliva --- --with-specs are quite useful to change compiler defaults, but I don't suppose you'll want to change them. I'd have added the options to BOOT_CFLAGS if that was as easy as --with-specs for a test build ;-) But you probably already know that ;-)
[Bug middle-end/121000] __builtin_dynamic_object_size should work for FAM with VLA element when annotated with counted_by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000 --- Comment #12 from GCC Commits --- The master branch has been updated by Qing Zhao : https://gcc.gnu.org/g:1cf8d08a977f528c6e81601b7586ccf8bc8aa2a6 commit r16-2180-g1cf8d08a977f528c6e81601b7586ccf8bc8aa2a6 Author: Qing Zhao Date: Wed Jul 9 20:10:30 2025 + Passing TYPE_SIZE_UNIT of the element as the 6th argument to .ACCESS_WITH_SIZE (PR121000) The size of the element of the FAM _cannot_ reliably depends on the original TYPE of the FAM that we passed as the 6th parameter to the .ACCESS_WITH_SIZE: TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (gimple_call_arg (call, 5 when the element of the FAM has a variable length type. Since the variable that represents TYPE_SIZE_UNIT has no explicit usage in the original IL, compiler transformations (such as DSE) that are applied before object_size phase might eliminate the whole definition to the variable that represents the TYPE_SIZE_UNIT of the element of the FAM. In order to resolve this issue, instead of passing the original TYPE of the FAM as the 6th argument to .ACCESS_WITH_SIZE, we should explicitly pass the original TYPE_SIZE_UNIT of the element TYPE of the FAM as the 6th argument to the call to .ACCESS_WITH_SIZE. PR middle-end/121000 gcc/c/ChangeLog: * c-typeck.cc (build_access_with_size_for_counted_by): Update comments. Pass TYPE_SIZE_UNIT of the element as the 6th argument. gcc/ChangeLog: * internal-fn.cc (expand_ACCESS_WITH_SIZE): Update comments. * internal-fn.def (ACCESS_WITH_SIZE): Update comments. * tree-object-size.cc (access_with_size_object_size): Update comments. Get the element_size from the 6th argument directly. gcc/testsuite/ChangeLog: * gcc.dg/flex-array-counted-by-pr121000.c: New test.
[Bug target/117366] [12/13/14/15/16 regression] arm thumb1 epilogue size optimizer violates -ffixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117366 --- Comment #7 from Matt Parks --- Created attachment 61834 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61834&action=edit Patch (also e-mailed to gcc-patches) Adding as text attachment because apparently my gcc-patches e-mail was not formatted correctly from my webmail client.
[Bug target/117468] [12/13/14/15/16 Regression] arm thumb1 high reg restoration trashes register reserved with -ffixed-reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117468 --- Comment #3 from Matt Parks --- Created attachment 61835 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61835&action=edit Patch (also e-mailed to gcc-patches) Adding patch as text attachment because apparently my e-mail to gcc-patches is not formatted correctly from my webmail client.
[Bug target/121028] New: Some tests added in r15-5785-gdfa78681851 fail with -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121028 Bug ID: 121028 Summary: Some tests added in r15-5785-gdfa78681851 fail with -fstack-protector-strong Product: gcc Version: 15.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: siddhesh at gcc dot gnu.org Target Milestone: --- The following tests fail when they're built with -fstack-protector-strong: gcc.target/aarch64/sve/acle/asm/ld2_mf8.c gcc.target/aarch64/sve/acle/asm/ld3_mf8.c gcc.target/aarch64/sve/acle/asm/ld4_mf8.c gcc.target/aarch64/sve/acle/asm/reinterpret_mf8.c because they generate `smstop sm`, which the assembler does not expect: /tmp/ccAM1BXW.s: Assembler messages: /tmp/ccAM1BXW.s:116: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:287: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:453: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:620: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:791: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:958: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:1125: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:1293: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:1461: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:1632: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:1796: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:1962: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:2128: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:2294: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:2460: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:2626: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:2792: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:2958: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:3124: Error: selected processor does not support `smstop sm' /tmp/ccAM1BXW.s:3297: Error: selected processor does not support `smstop sm' They're built with -march=armv8.2-a+sve and they work just fine when built without stack-protector. However when built with -fstack-protector-strong, the functions end up with a `smstop sm` just before the __stack_chk_fail call. This seems wrong since the assembler only expects `smstop` with -march=armv8.2-a+sve2+sme. To reproduce: gcc/xgcc -Bgcc -fstack-protector-strong -std=c90 -O0 -DSTREAMING_COMPATIBLE -DTEST_FULL -march=armv8.2-a+sve -c -o ld2_mf8.s ../gcc/testsuite/gcc.target/aarch64/sve/acle/asm/ld2_mf8.c
[Bug objc/119117] [12/13/14/15/16 Regression] instance variables sometimes causes unknown type name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119117 Andrew Pinski changed: What|Removed |Added CC||ats-gccbugs at offog dot org --- Comment #7 from Andrew Pinski --- *** Bug 121031 has been marked as a duplicate of this bug. ***
[Bug objc/121031] if condition misparsed as declaration in Objective C method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121031 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 119117 ***
[Bug objc/121031] New: if condition misparsed as declaration in Objective C method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121031 Bug ID: 121031 Summary: if condition misparsed as declaration in Objective C method Product: gcc Version: 15.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc Assignee: unassigned at gcc dot gnu.org Reporter: ats-gccbugs at offog dot org CC: iains at gcc dot gnu.org Target Milestone: --- Created attachment 61836 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61836&action=edit Minimised example The attached example is minimised from Oolite's OOPriorityQueue.m. There are a couple of cases in Oolite where GCC 15.1.0 is apparently misparsing a straightforward if condition as a pointer declaration (https://github.com/OoliteProject/oolite/pull/520) - adding brackets around the LHS makes it happy. Compiling with GCC 15.1.0 fails like this: $ gcc -v -c ifparse.m Using built-in specs. COLLECT_GCC=gcc Target: x86_64-pc-linux-gnu Configured with: /src/devel/gcc/work/gcc-15.1.0/configure --prefix=/gar --sysconfdir=/etc --localstatedir=/var --sharedstatedir=/var/com --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --enable-__cxa_atexit --enable-threads=posix --enable-shared --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --with-local-prefix=/gar --disable-multilib --with-system-zlib Thread model: posix Supported LTO compression algorithms: zlib gcc version 15.1.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /gar/packages/gcc-15.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.1.0/cc1obj -quiet -v -iprefix /gar/packages/gcc-15.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/15.1.0/ ifparse.m -quiet -dumpbase ifparse.m -dumpbase-ext .m -mtune=generic -march=x86-64 -version -o /tmp/cccqBcCZ.s GNU Objective-C (GCC) version 15.1.0 (x86_64-pc-linux-gnu) compiled by GNU C version 15.1.0, GMP version 6.3.0, MPFR version 4.2.2, MPC version 1.3.1, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/gar/packages/gcc-15.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/15.1.0/../../../../x86_64-pc-linux-gnu/include" ignoring duplicate directory "/gar/packages/gcc-15.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/15.1.0/include" ignoring duplicate directory "/gar/packages/gcc-15.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/15.1.0/include-fixed" ignoring nonexistent directory "/gar/packages/gcc-15.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/15.1.0/../../../../x86_64-pc-linux-gnu/include" ignoring duplicate directory "/usr/include" #include "..." search starts here: #include <...> search starts here: /gar/packages/gcc-15.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/15.1.0/include /gar/packages/gcc-15.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/15.1.0/include-fixed /gar/include End of search list. Compiler executable checksum: 7eea9bb219287c09feb0e71d34f602c8 ifparse.m:13:1: warning: class ‘OOPriorityQueue’ defined without specifying a base class [-Wobjc-root-class] 13 | - (void)removeObjectAtIndex:(int)i | ^ ifparse.m: In function ‘-[OOPriorityQueue removeObjectAtIndex:]’: ifparse.m:15:13: error: unknown type name ‘_count’ 15 | if (_count * 2 < _count) | ^~ ifparse.m:15:22: error: expected identifier or ‘(’ before numeric constant 15 | if (_count * 2 < _count) | ^ ifparse.m:15:13: error: declaration in the controlling expression must have an initializer 15 | if (_count * 2 < _count) | ^~ Here's this example on Compiler Explorer: https://godbolt.org/z/5sfvxTbWe It fails there with trunk and 15.1.0, and works with 14.3 and older versions.
