fortran: Fix ICE in gfc_trans_auto_array_allocation with scalar coarray [PR93715]
A scalar coarray variable (e.g. integer :: b[*]) used in asynchronous
I/O causes an ICE in gfc_trans_auto_array_allocation because the
variable reaches gfc_trans_auto_array_allocation which asserts
GFC_ARRAY_TYPE_P on the backend declaration type. For scalar coarrays,
the backend type is a plain scalar, not a GFC array type.
The root cause is in gfc_trans_deferred_vars: scalar coarray variables
enter the AS_EXPLICIT case because sym->attr.codimension is set and the
coarray spec type is AS_EXPLICIT. The existing guard for static coarray
variables does not catch non-static scalar coarrays, so they fall
through to gfc_trans_auto_array_allocation.
Add a check for scalar coarrays (codimension without dimension) to skip
array allocation, since these variables have no array rank and do not
need auto array allocation.
2026-04-08 Paul Thomas <pault@gcc.gnu.org>
PR fortran/93715
gcc/fortran
* trans-decl.cc (gfc_trans_deferred_vars): Skip auto array
allocation for scalar coarrays.
gcc/testsuite
* gfortran.dg/pr93715.f90: New test.
Signed-off-by: Christopher Albert <albert@tugraz.at>
[auto-profile] Improve handling of timestamp merging.
The following condition:
if (other->timestamp() < timestamp())
set_timestamp (other->timetamp())
would set timestamp() to 0 if other->timestamp() was zero effectively
dropping the symbol from time-profile based reordering.
The patch fixes this by ensuring other->timestamp() is greater than zero.
Also, handles the case when timestamp() is zero but other->timestamp() is non-zero.
gcc/ChangeLog:
* auto-profile.cc (function_instance::merge): Set other->timestamp() if it's
lesser than timestamp() and greater than zero or if timestamp() is zero.
Jakub Jelinek [Wed, 8 Apr 2026 05:46:38 +0000 (07:46 +0200)]
c++: Implement CWG3135 - constexpr structured bindings with prvalues from tuples
The following patch implements another CWG issue, added e.g. for the
P1789R3 (Library Support for Expansion Statements) APIs where get returns
a prvalue rather than a reference.
While the issue has been voted as a non-DR, this implementation assumes it
will be changed to a DR. If that won't be the case, we will need to limit
the changes to C++26 and later only.
The gomp testcase was using get returning prvalue and the changes
cause some changes in lines on which stuff is reported.
2026-04-08 Jakub Jelinek <jakub@redhat.com>
* decl.cc (cp_finish_decomp): Implement CWG3135 - constexpr structured
bindings with prvalues from tuples (as a DR). Don't call
cp_build_reference_type if init is prvalue.
* g++.dg/cpp26/decomp30.C: New test.
* g++.dg/gomp/pr108503.C: Adjust expected diagnostic locations.
libphobos: Skip math.hardware unittests on targets without IEEE flags support [PR123202]
PR d/123202
libphobos/ChangeLog:
* testsuite/lib/libphobos.exp
(check_effective_target_phobos_ieee_flags_support): New proc.
* testsuite/libphobos.phobos/phobos.exp: Skip math/hardware.d tests if
target does not have phobos_iee_flags_support.
* testsuite/libphobos.phobos/shared/phobos-shared.exp: Likewise.
* testsuite/libphobos.phobos/static/phobos-static.exp: Likewise.
fortran: Reject array/allocatable LINEAR on DO [PR102430]
The middle-end does not implement array/allocatable LINEAR for OpenMP
worksharing loops, which can ICE during OpenMP expansion. Diagnose this
case in the Fortran front end with a sorry message instead.
PR fortran/102430
gcc/fortran/ChangeLog:
* openmp.cc (resolve_omp_clauses): Reject array/allocatable LINEAR on
worksharing-loop constructs.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/pr102430.f90: New test.
Signed-off-by: Christopher Albert <albert@tugraz.at>
if (!TEST_HARD_REG_BIT (hard_stack_slot_access, regno))
...
symbolic_const_load_p = true;
...
if (!symbolic_const_load_p
|| ix86_access_stack_p...)
call ix86_update_stack_alignment.
with
if (ix86_need_alignment_p...
&& ix86_access_stack_p...)
call ix86_update_stack_alignment.
Since ix86_access_stack_p excludes registers on hard_stack_slot_access,
stack alignment isn't updated for registers on hard_stack_slot_access.
Instead, we should do
if (ix86_need_alignment_p...
&& (TEST_HARD_REG_BIT (hard_stack_slot_access, regno)
|| ix86_access_stack_p...))
call ix86_update_stack_alignment.
The compile times of PR target/124165 and PR target/124684 test are
unchanged.
if (ix86_need_alignment_p...
&& (TEST_HARD_REG_BIT (hard_stack_slot_access, regno)
|| ix86_access_stack_p...))
call ix86_update_stack_alignment.
gcc/
PR target/124759
PR target/124789
* config/i386/i386.cc (ix86_need_alignment_p_2): New function.
Exclude memory with SYMBOLIC_CONST.
(ix86_need_alignment_p_1): Call ix86_need_alignment_p_2.
(ix86_find_max_used_stack_alignment): Restore
hard_stack_slot_access handling.
gcc/testsuite/
PR target/124759
PR target/124789
* gcc.target/i386/pr124759.c: New test.
We have some permute SLP nodes which still have a SLP_TREE_REPRESENTATIVE,
so make sure we're not facing a permute note when trying to perform
SLP pattern matching.
PR tree-optimization/124802
* tree-vect-slp-patterns.cc (vect_match_expression_p): Fail
for SLP_TREE_PERMUTE_P.
Tomasz Kamiński [Wed, 1 Apr 2026 12:32:21 +0000 (14:32 +0200)]
libstdc++: Export explicit instantiations for C++20 members of std::string
The C++20 standard added new starts_with and ends_with members to
std::basic_string, which were not previously instantiated in the library.
This meant that the extern template declarations had to be disabled for
C++20 mode. With this patch the new members are instantiated in the
library and so the explicit instantiation declarations can be used for
C++20.
Furthermore, basic_string default constructor is now constrained with
is_default_constructible_v<_Alloc> constrains, that is included in
mangled name, so we also need to instantiate and export it.
The new members added by C++23 are still not exported, and so the
explicit instantiation declarations are still disabled for C++23.
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu.ver (GLIBCXX_3.4): Make string exports
less greedy.
(GLIBCXX_3.4.35): Export basic_string default constructor and
starts_with and ends_with members.
* include/bits/basic_string.h: Update __cpluplus checks for C++20.
* include/bits/cow_string.h: Likewise.
* include/bits/basic_string.tcc: Declare explicit instantiations
for C++20 as well as earlier dialects.
* src/c++20/Makefile.am: Add cow-string-inst.cc and
string-inst.cc source files.
* src/c++20/Makefile.in: Regenerate.
* src/c++20/string-inst.cc: New file defining explicit
instantiations for basic_string default constructor and starts_with,
ends_with methods added in C++20
* src/c++20/cow-string-inst.cc: Version of above for cow-stings.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
fortran: Fix ICE in gfc_conv_array_initializer with invalid index [PR103367]
An undefined variable used as an array index in a parameter initializer
expression reaches gfc_conv_array_initializer after parameter substitution
with an unexpected expression type, hitting gcc_unreachable().
Guard against unexpected expression types by returning a zero-filled
constructor, since the frontend has already diagnosed the error.
PR fortran/103367
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_conv_array_initializer): Return empty
constructor for unexpected expression types after parameter
substitution.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr103367.f90: New test.
Signed-off-by: Christopher Albert <albert@tugraz.at>
doc: Make regenerate-opt-urls.py handle two-dash options [PR124784]
I was puzzled as to why the generated config/picolib.opt.urls
contained no entries. It turns out this was a general problem with
regenerate-opt-urls.py failing to handle options starting with two dashes,
which are listed with one dash in the .opt file but zero dashes (same as
one-dash options) in the index entries. The solution here is to remove one
of the dashes when canonicalizing the option name for lookup in the index.
gcc/ChangeLog
PR other/124784
* regenerate-opt-urls.py (canonicalize_option_name): Remove one
of the dashes from option names starting with two dashes.
(test_parse_option_index): Add a self-test for this.
* common.opt.urls: Regenerated.
* config/picolibc.opt.urls: Regenerated.
Patrick Palka [Tue, 7 Apr 2026 16:28:44 +0000 (12:28 -0400)]
c++: template-id typedef with lambda targ [PR123700]
A typedef to a template-id with a lambda targ must not be stripped by
strip_typedefs because it can cause the lambda to leak into a deeper
template context, which breaks substituting into the lambda later.
For example in the below testcases zero<inner> gets stripped to
zero<Type<[](auto) {}>>, and we end up substituting through this
lambda targ twice (with args {double} then {int}) even though the lambda
is from a depth-one template context.
This patch extends the existing lambda typedef handling in
dependent_opaque_alias_p (added by r15-3694 for decltype(lambda))
to also recognize such template-id typedefs. This should recognize
the vast majority of such constructs in practice (though the lambda
could also be a subexpression within a template argument which this
won't recognize).
PR c++/123700
gcc/cp/ChangeLog:
* pt.cc (dependent_opaque_alias_p): Return true for a
template-id typedef with a lambda targ.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-targ24.C: New test.
* g++.dg/cpp2a/lambda-targ24a.C: New test.
Patrick Palka [Tue, 7 Apr 2026 16:28:42 +0000 (12:28 -0400)]
c++: templated static local var has value-dep addr, cont [PR123529]
has_value_dependent_address for a static local variable checks type
dependence of its context, but that's too narrow and we need a more
general dependence check that considers outer template arguments as
well, so that in the testcase below we deem A<T>::g()::i to have a
value-dependent address (making f<&i>() a dependent call).
PR c++/123529
PR c++/98930
gcc/cp/ChangeLog:
* pt.cc (has_value_dependent_address): Correct context
dependence check for a static local variable.
Jakub Jelinek [Tue, 7 Apr 2026 16:13:55 +0000 (18:13 +0200)]
c++: Implement CWG3140 - Allowing expansion over non-constant std::array
The following patch implements CWG3140, which allows non-constexpr
iterating expansion statements over non-constexpr ranges like std::array
where the range size is still known at compile time.
On the other side it breaks iterating expansion statements without constexpr
keyword on range-decl over ranges where to find out the range size the range
needs to be accessed. In some cases one will have to just add the constexpr
keyword, in other cases even that doesn't have to work (e.g. when the
iterator is constexpr except for operator* or some non-constexpr conversion
operator is involved).
2026-04-07 Jakub Jelinek <jakub@redhat.com>
* cp-tree.h: Implement C++26 CWG3140 - Allowing expansion over
non-constant std::array.
(cp_build_range_for_decls): Change last argument from bool to tree.
(build_range_temp): Likewise and default it to NULL_TREE rather than
false.
* parser.cc (build_range_temp): Remove expansion_stmt_p
argument, add expansion_stmt_decl. Don't call cp_build_qualified_type
if expansion_stmt_decl was not declared constexpr.
(cp_build_range_for_decls): Remove expansion_stmt_p argument, add
expansion_stmt_decl. Pass expansion_stmt_decl to build_range_temp.
Don't set TREE_STATIC, TREE_PUBLIC, DECL_COMMON, DECL_INTERFACE_KNOWN,
DECL_DECLARED_CONSTEXPR_P and TREE_READONLY on range_temp if
expansion_stmt_decl was not declared constexpr. Don't call
cp_build_qualified_type on begin type nor set TREE_STATIC etc. on begin
if expansion_stmt_decl was not declared constexpr. If
expansion_stmt_decl is non-NULL, don't build end at all, instead pass
begin_expr and end_expr in end_p[0] and end_p[1] to the caller.
(cp_convert_range_for): Adjust cp_build_range_for_decls caller.
* pt.cc (finish_expansion_stmt): Likewise. Use begin_expr and end_expr
instead of begin and end variables from cp_build_range_for_decls,
make them non-constant and avoid spurious -Wunused-result/nodiscard
diagnostics.
* g++.dg/cpp26/expansion-stmt11.C: Expect some extra diagnostics for
C++11.
* g++.dg/cpp26/expansion-stmt13.C: Likewise. Make it dg-do compile
test for c++11_only and dg-do run only for c++14 and above.
* g++.dg/cpp26/expansion-stmt16.C: Adjust expected diagnostics.
* g++.dg/cpp26/expansion-stmt19.C: Expect some extra diagnostics for
C++11. Make it dg-do compile test for c++11_only and dg-do run only
for c++14 and above.
* g++.dg/cpp26/expansion-stmt25.C (foo): Test both constexpr
range-for-decl and non-constexpr, adjust expected diagnostics.
* g++.dg/cpp26/expansion-stmt30.C: Adjust expected diagnostics.
* g++.dg/cpp26/expansion-stmt35.C: New test.
* g++.dg/cpp26/expansion-stmt36.C: New test.
* g++.dg/cpp26/expansion-stmt37.C: New test.
* g++.dg/cpp26/expansion-stmt38.C: New test.
Jakub Jelinek [Tue, 7 Apr 2026 16:00:24 +0000 (18:00 +0200)]
c++: Implement mangling for partially instantiated C++26 pack indexing [PR124487]
On Fri, Apr 03, 2026 at 05:56:08PM -0400, Jason Merrill wrote:
> Regarding the TODO, the related case I was thinking about was
>
> > ::= sZ <template-param> # sizeof...(T), size of a template parameter pack
> > ::= sP <template-arg>* E # sizeof...(T), size of a captured template parameter pack from an alias template
>
> ...but rather than follow the precedent of a different two-letter
> abbreviation, I might use J...E to express the expanded pack, as in
> <template-arg>. I've now suggested that on the ABI issue, as well.
Here is a patch which implements it.
2026-04-07 Jakub Jelinek <jakub@redhat.com>
PR c++/124487
* mangle.cc (write_type) <case PACK_INDEX_TYPE>: Handle even
the case of partially substituted pack.
(write_expression): Similarly for PACK_INDEX_EXPR.
* g++.dg/cpp26/pack-indexing9.C: Remove dg-sorry/dg-bogus, add
tests for mangled names and further test coverage.
Jakub Jelinek [Tue, 7 Apr 2026 15:59:13 +0000 (17:59 +0200)]
c++: Mark reflected vars/parameters as read [PR124790]
This PR complains about spurious -Wunused-but-set-* warnings when using
reflections. E.g. there is no warning for variable just set and used in
sizeof (var), but there is one when using size_of (^^var). If we reflect
some variable or parameter, we can do all kinds of things with it, so
setting preventing these warnings is IMHO desirable.
2026-04-07 Jakub Jelinek <jakub@redhat.com>
PR c++/124790
* reflect.cc (get_reflection): When reflecting VAR_DECL or PARM_DECL,
call mark_exp_read on it.
Remember the dummy whose bounds or character length are currently being
resolved as a specification expression so sibling ENTRY arguments in the
same unresolved ENTRY can be accepted.
2026-04-07 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/85352
* resolve.cc (specification_expr_symbol): New variable.
(entry_dummy_seen_p): Return whether a dummy appears in an already
seen ENTRY.
(gfc_resolve_formal_arglist): Remember the dummy whose specification
expressions are being resolved.
(resolve_variable): Accept unresolved sibling ENTRY dummy arguments
while resolving the current dummy's specification expressions.
(resolve_fl_variable): Preserve specification_expr_symbol.
(resolve_symbol_array_spec): Likewise.
gcc/testsuite
PR fortran/85352
* gfortran.dg/pr85352.f90: New test.
Signed-off-by: Christopher Albert <albert@tugraz.at>
Peter Damianov [Sun, 5 Apr 2026 00:41:04 +0000 (01:41 +0100)]
mingw: Remove obsolete STMP_FIXINC override from t-cygming
The STMP_FIXINC assignment in t-cygming dates back to r0-48723-g70e5e841b8b931, which introduced the shared cygwin/mingw
makefile fragment and used it to force fixincludes on for those
targets.
That predates r0-63200-g53c7ffe7dd1c28, which made configure default
STMP_FIXINC to stmp-fixinc, so the t-cygming assignment is now
redundant in normal builds. Once --disable-fixincludes was added by r13-2319-gbe9dd80f933480, the old override became incorrect as well,
because it forced stmp-fixinc back on for targets using t-cygming.
Configuring for mingw targets with --disable-fixincludes would then
fail with:
make[1]: No rule to make target
'../build-x86_64-pc-linux-gnu/fixincludes/fixinc.sh', needed by 'stmp-fixinc'.
Stop.
Remove the obsolete assignment so the configure-time default is used,
including when honoring an explicit --disable-fixincludes.
Richard Biener [Wed, 1 Apr 2026 10:39:43 +0000 (12:39 +0200)]
tree-optimization/124743 - SLP scheduling of invariant internal ops
The following makes us avoid scheduling invariant internal operations
to random points in the CFG when doing loop vectorization since
in that case the stmt UIDs we use for dominance checks are not
initialized outside of loop bodies. Instead schedule such
operations by appending to the loop preheader which is where
invariants generally end up for loop vectorization.
PR tree-optimization/124743
* tree-vect-slp.cc (vect_schedule_slp_node): Schedule
loop invariant operations in the loop preheader.
fortran: Fix ICE with implicit variable in iterator depend clause [PR107425]
An implicitly typed variable used as a subscript in an OpenMP iterator
depend clause (e.g., x(j) where j is implicit and only referenced in
the clause) caused an ICE in gimplify_var_or_parm_decl because the
variable's decl was never associated with a BIND_EXPR.
The root cause is that gfc_match_iterator creates a block namespace
(via gfc_build_block_ns) for iterator variables. When the locator
expression x(j) is parsed with gfc_current_ns set to this iterator
namespace, the implicit variable j is created there rather than in the
enclosing program namespace. In gfc_finish_var_decl, the FL_LABEL
check for BLOCK constructs matched before the omp_affinity_iterators
check, routing j through add_decl_as_local. Unlike real BLOCK
construct variables, these never get a proper BIND_EXPR, so the
gimplifier rejects them.
Fixed by checking for omp_affinity_iterators before the FL_LABEL
BLOCK construct check, and only treating actual iterator variables
(those on the omp_affinity_iterators chain) as block-local. Other
variables in the iterator namespace are added to the enclosing
function scope.
2026-04-07 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/107425
* trans-decl.cc (gfc_finish_var_decl): Check for
omp_affinity_iterators namespace before FL_LABEL BLOCK check.
Only route actual iterator variables through add_decl_as_local;
add other variables to the enclosing function.
gcc/testsuite
PR fortran/107425
* gfortran.dg/gomp/pr107425.f90: New test.
Signed-off-by: Christopher Albert <albert@tugraz.at>
Paul Thomas [Sun, 5 Apr 2026 09:53:08 +0000 (10:53 +0100)]
Fortran: Bugs found while testing r16-8436 [PR124780]
2026-04-07 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/124780
* resolve.cc (resolve_ordinary_assign): Do not add the class
data component to an operator expression.
* trans-expr.cc (gfc_trans_scalar_assign): If class to class
assignment uses ordinary scalar assignment and neither lhs or
rhs are class types, do a deep copy for allocatable components.
gcc/testsuite/
PR fortran/124780
* gfortran.dg/pr124780.f90: New test.
testsuite: fork does not work for bare metal targets
For an arm-none-eabi toolchain, at least built with newlib, the fork()
function exists, but it returns failure. The implementation is part of
libnosys.a and is there only to allow linking (runtime failure).
gcc/testsuite/ChangeLog:
* lib/target-supports.exp (check_fork_runtime): New function to
check that target has a working fork() implementation.
* lib/target-supports-dg.exp (dg-require-fork): When test is
"run", then call check_fork_runtime, else check_fork_available.
Avinash Jayakar [Tue, 24 Mar 2026 04:29:02 +0000 (23:29 -0500)]
rs6000: Add new builtin __builtin_ppc_atomic_cas_local
This patch adds a new powerpc specific atomic builtin which is similar
to the generic __atomic_compare_exchange builtin.
bool __builtin_ppc_atomic_cas_local (type *ptr, type *expected,
type *desired, bool weak,
int success_memorder,
int failure_memorder)
It behaves like __atomic_compare_exchange(), but it uses an EH value of
1 in the larx (load-and-reserve) instruction. The new builtin helps
optimize lock contention on PowerPC by keeping the lock cacheline in
the local processor longer, reducing performance penalties from
cache coherence protocol traffic.
* config/rs6000/rs6000-builtin.cc (rs6000_expand_builtin): Add
logic to handle __builtin_ppc_atomic_cas_local.
* config/rs6000/rs6000-builtins.def: New builtins for
__builtin_ppc_atomic_cas_local with types.
* config/rs6000/rs6000-c.cc (altivec_build_resolved_builtin):
Handle builtins with up to 6 arguments.
* config/rs6000/rs6000-overload.def: Overload builtin for
signed/unsiged char, short, int, long, __int128.
* config/rs6000/rs6000-protos.h (rs6000_expand_atomic_compare_and_swap):
Add additional parameter 'local' to the prototype.
* config/rs6000/rs6000.cc (emit_load_locked): Add new parameter. Pass
new parameter to generate load-locked instruction.
(rs6000_expand_atomic_compare_and_swap): Add new parameter. Call
emit_load_locked() with additional parameter value of EH bit.
(rs6000_expand_atomic_exchange): Pass EH value 0 to emit_load_locked().
(rs6000_expand_atomic_op): Likewise.
* config/rs6000/sync.md (load_locked<mode>): Add new operand in RTL
template. Specify EH bit in the larx instruction.
(load_locked<QHI:mode>_si): Likewise.
(load_lockedpti): Likewise.
(load_lockedti): Add new operand in RTL template. Pass EH bit to
gen_load_lockedpti().
(atomic_compare_and_swap<mode>): Pass new parameter 'false' to
rs6000_expand_atomic_compare_and_swap.
(atomic_compare_and_swap_local<mode>): New define_expand.
Nathaniel Shead [Thu, 19 Mar 2026 12:58:30 +0000 (23:58 +1100)]
c++/modules: Allow exporting usings of internal GMF entities with pedwarn [PR124268]
As discussed in libstdc++/124268, the std module relies on exporting
using-declarations for various entities, but on some targets the
relevant declarations have internal linkage.
Given we already support exposures of such internal linkage entities for
migration purposes, it seems reasonable to allow the same for
using-declarations.
PR libstdc++/124268
gcc/ChangeLog:
* doc/invoke.texi: Note that -Wexpose-global-module-tu-local
also applies to 'export using' declarations.
gcc/cp/ChangeLog:
* module.cc (instantiating_tu_local_entity): Use pedwarn instead
of warning.
(depset::hash::add_binding_entity): Don't skip exported
using-decls as TU-local entities.
(depset::hash::finalize_dependencies): Don't attempt to complain
again about using-decls referencing TU-local entities.
* name-lookup.cc (check_can_export_using_decl): Demote the error
to a warning for using-decls of GMF vars or functions.
gcc/testsuite/ChangeLog:
* g++.dg/modules/using-34_a.C: New test.
* g++.dg/modules/using-34_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Patrick Palka <ppalka@redhat.com> Reviewed-by: Jason Merrill <jason@redhat.com>
c++/modules: Handle importing an undeduced auto over a deduced auto [PR124735]
Like with implicit constexpr, we need to handle cases where we import an
function declaration with undeduced auto, but we already have a
definition available with deduced auto. In this case we can just keep
the existing declaration's type.
PR c++/124735
gcc/cp/ChangeLog:
* module.cc (trees_in::is_matching_decl): Handle importing
undeduced auto when existing is already deduced.
gcc/testsuite/ChangeLog:
* g++.dg/modules/auto-8_a.H: New test.
* g++.dg/modules/auto-8_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
c++/modules: Only mark namespace-scope entities as exported [PR124781]
We call 'set_originating_module' before we call pushdecl, which means
that for function-scope entities we might not have set DECL_CONTEXT yet.
Usually this doesn't matter, we only look at DECL_MODULE_EXPORT/ATTACH_P
on namespace-scope entities to begin with, but in the case in the linked
PR it causes issues because declarations in an unevaluated lambda appear
to be in an internal context.
Fixed by only considering non-null DECL_CONTEXT as being namespace scope
within set_originating_module.
As a drive-by improvement, ensured that we only talk about unnamed
namespaces in the diagnostic within check_module_decl_linkage if we're
actually within an anonymous namespace; this should be equivalent but
will lead to a slightly clearer diagnostic if a similar bug crops up
again later.
PR c++/124781
gcc/cp/ChangeLog:
* module.cc (set_originating_module): Add a function comment,
only set attachment/exporting for entities with non-NULL
DECL_CONTEXT.
(check_module_decl_linkage): Use decl_anon_ns_mem_p instead of
decl_internal_context_p.
gcc/testsuite/ChangeLog:
* g++.dg/modules/export-7.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
c++/modules: Fix propagating noexcept for templates [PR124785]
We triggered a checking assertion because when propagating deduced
noexcept, we were updating the type of the existing TEMPLATE_DECL but
not the type of its DECL_TEMPLATE_RESULT, violating assumptions made
later on during modules streaming.
But actually there was nothing to propagate here anyway, these
declarations are identical, so this patch also fixes the condition for
checking whether we need to propagate anything. And so now I don't
think there is ever a case we should have a noexcept-spec to propagate
for a TEMPLATE_DECL, so add an assertion to validate this.
PR c++/124785
gcc/cp/ChangeLog:
* module.cc (trees_in::is_matching_decl): Narrow condition for
when noexcept propagation occurs; assert that we don't propagate
noexcept-specs for TEMPLATE_DECLs.
gcc/testsuite/ChangeLog:
* g++.dg/modules/noexcept-5.h: New test.
* g++.dg/modules/noexcept-5_a.C: New test.
* g++.dg/modules/noexcept-5_b.C: New test.
* g++.dg/modules/noexcept-5_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
c++/modules: Fix entry-point detection for recursive clusters [PR118630]
In r15-4861-g4a99443c5dd9a235022652ba0fb143c6370ea99d we added support
to handle recursive dependency clusters, where we need to find the
"entry" dependency that all other entities will hook off to ensure that
we stream merge keys in the correct order on read-in.
The logic I'd used to track the entry bit was not completely correct
however, leading to assertion failures in 'sort_cluster' where we found
that entities were not marked maybe_recursive when they should have
been, or multiple entities were marked as the entry point.
Consider a cycle of three entities in a cluster, 'A', 'B', and 'C',
where 'A' is the entry point. By definition we walk into 'A' first, and
find one of the other entities, 'B'. The old logic marked 'A' as the
entry and 'B' as maybe-recursive; so far this is correct.
But then if we walk into 'B' and find 'C' is maybe-recursive, the old
logic would mark 'B' as the entry point (again!). And likewise when we
walk into 'C' and find 'A'. So we would end up with three entry points.
Similar issues could happen with other arrangements of dependencies.
Instead, by aggressively marking everything we see as maybe-recursive,
and only marking an entry point if nothing we see is maybe-recursive, we
avoid this issue. We should only be able to discover these other
entities through the entry point (A) and so this 'flood fill' behaviour
should ensure that all entities are correctly marked maybe-recursive,
and only A is marked as an entry-point.
PR c++/118630
gcc/cp/ChangeLog:
* module.cc (depset::hash::add_dependency): Correct entry point
corection for recursive clusters.
gcc/testsuite/ChangeLog:
* g++.dg/modules/late-ret-5.h: New test.
* g++.dg/modules/late-ret-5_a.H: New test.
* g++.dg/modules/late-ret-5_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Jakub Jelinek [Mon, 6 Apr 2026 21:10:46 +0000 (23:10 +0200)]
c++: Fix up handling of for-range-decls of expansion stmt [PR124488]
The following testcase is rejected, because we don't set all the needed
flags on range_decl in cp_parser_expansion_statement. During parsing
of the expansion stmt body, it should be treated as if there is a decl
with value dependent initializer in a template, because the value it will
have is yet to be determined (and possibly different in each instantiation
of the body).
For such decls, cp_finish_decl normally conservatively sets
DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (because it might be initialized
by constant expression) and for non-references also sets TREE_CONSTANT
if decl_maybe_constant_var_p. Furthermore, those have a value dependent
initializer and DECL_DEPENDENT_INIT_P is set on those too.
The following patch arranges all of that for the range_decl.
2026-04-06 Jakub Jelinek <jakub@redhat.com>
PR c++/124488
* parser.cc (cp_parser_expansion_statement): Set
DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P, DECL_DEPENDENT_INIT_P and
if maybe constant non-reference TREE_CONSTANT on range_decl.
* pt.cc (tsubst_stmt) <case TEMPLATE_FOR_STMT>: Set
DECL_DEPENDENT_INIT_P on decl.
Jakub Jelinek [Mon, 6 Apr 2026 21:08:48 +0000 (23:08 +0200)]
c++: Implement the annotations_of on parms part of P3795R2
The current behavior of GCC is that we list all annotations gathered from
all the PARM_DECLs merged together on ^^fnparm or
variable_of (parameters_of (^^fn)[0]) and throw on annotations_of
on parameters_of (^^fn)[0]. The paper requires that the last one works
like we currently handle the former two, and for the former two we
filter out annotations that have not appeared on the function definition.
The following patch marks the annotations in grokfndecl before pushdecl
etc. merges it with other decls.
2026-04-06 Jakub Jelinek <jakub@redhat.com>
* decl.cc (grokfndecl): For -freflection mark annotations of
PARM_DECLs in a function definition.
* reflect.cc (eval_annotations_of): Allow annotations_of on
function parameters. For r which is a PARM_DECL without REFLECT_PARM,
filter out annotations not marked by grokfndecl.
(reflection_mangle_prefix): Preserve the grokfndecl marking of
annotations during mangling.
doc: Rewrite Solaris section of install.texi for GCC 16
The Solaris installation information in install.texi urgently needed a
rewrite. It was highly repetitive, with information spread over both a
generic Solaris section and several separate ones for the different
configurations, and contained lots of cruft that's no longer relevant.
This patch merges all of them into a single Solaris section and attempts
a concise documentation of the requirements, configuration options and
quirks.
Without SSE2 double precision uses excess precision, leading to test
failures. For now, std::simd remains a tech preview that simply is
disabled without SSE2.
fortran: Clean up charlens after rejected parameter arrays [PR79524]
When a parameter array declaration such as
character(*), parameter :: z(2) = [character(n) :: 'x', 'y']
is rejected, declaration-local charlen nodes from that statement can remain on
cl_list and later be resolved again. The charlen's length expression still
references the symbol 'n' whose symtree was already freed by gfc_undo_symbols,
causing a heap-use-after-free in resolve_charlen.
Clean up those statement-local charlens at the rejection point in decl.cc,
after clearing the surviving owners in that path.
PR fortran/79524
gcc/fortran/ChangeLog:
PR fortran/79524
* decl.cc (discard_pending_charlens): New helper.
(add_init_expr_to_sym): Drop statement-local charlens when
rejecting variable-length parameter arrays.
(variable_decl, do_parm, enumerator_decl): Save the current
namespace charlen list before parsing declarations with
initializers.
(match_procedure_decl): Adjust call to add_init_expr_to_sym.
gcc/testsuite/ChangeLog:
PR fortran/79524
* gfortran.dg/pr79524.f90: New test.
Signed-off-by: Christopher Albert <albert@tugraz.at>
While the error message isn't particularly helpful, it's from dg.exp
(dg-do): like the other dg-* procs it expects the line number to be the
first argument. However, dg-do-if strips that, so dg-do gets the target
selector instead of the expected action keyword.
Fixed by no longer stripping the line number.
Tested on amd64-pc-freebsd15.0 (sse2_runtime && !sse4_runtime),
i386-pc-solaris2.11 and x86_64-pc-linux-gnu (sse2_runtime &&
sse4_runtime).
Jakub Jelinek [Sun, 5 Apr 2026 16:06:34 +0000 (18:06 +0200)]
c++: Error recovery for fuzzed <meta> [PR124689]
I knew this was coming, but hoped it would come later ;)
Basically, when one preprocesses <meta> + some reflection code and
attempts to fuzz it, we can ICE in various ways as we expect a sane
<meta>. In various places we've already tried to be defensive, error
out e.g. when we don't find the members we are looking for in <meta>
classes etc., plus when adding metafns.gperf I've added to the details
about each metafn the types of arguments and return type (which was
only partially used to evaluate e.g. the arguments in different ways
and prepare for the eval_* handlers, but checking of the types
wasn't actually done.
This patch introduces some limited checking of the return type and
argument types to make sure they are sane. Plus I've noticed the
can_substitute marking said incorrectly it returns info when it returns
bool.
The reflection_range/input_range arguments aren't checked, because they
can be all kinds of things and get_range_elts already does a lot of
checking. Similarly METAFN_KIND_ARG_TEMPLATE_PARM*, those aren't even
argument types, just a hack to tell the code that it needs to supply
the template parameter to the eval_* handlers.
2026-04-05 Jakub Jelinek <jakub@redhat.com>
PR c++/124689
* metafns.gperf (enum metafn_kind): Add
METAFN_KIND_BOOL_INFO_REFLECTION_RANGE.
(can_substitute): Use METAFN_KIND_BOOL_INFO_REFLECTION_RANGE
instead of METAFN_KIND_INFO_INFO_REFLECTION_RANGE.
(METAFN_KIND_ARG): Add MINFO argument.
(METAFN_KIND_RET): Define.
* reflect.cc (is_std_meta_class): New function.
(get_info): Add LOC argument, diagnose invalid argument type instead
of failing assertion.
(check_metafn_arg_type): New function.
(check_metafn_return_type): New function.
(process_metafunction): Diagnose clearly invalid return
or argument types. Use rettype variable instead of TREE_TYPE (call).
* metafns.h: Regenerate.
fortran: Fix character SPREAD intrinsic lowering [PR109788]
Copy the SPREAD intrinsic descriptor before specializing the character
formal argument type so other uses keep the generic signature.
PR fortran/109788
gcc/fortran/ChangeLog:
* iresolve.cc (copy_intrinsic_sym): New helper.
(gfc_resolve_spread): Copy the intrinsic descriptor before
specializing the character formal argument type.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr109788.f90: New test.
Signed-off-by: Christopher Albert <albert@tugraz.at>
Eric Botcazou [Sun, 5 Apr 2026 08:21:46 +0000 (10:21 +0200)]
Ada: Fix too large secondary stack allocation for aggregate return
This is a regression present on the mainline and 15 branch. The problematic
allocation may occur when the result type of the function is a discriminated
record type with defaulted discriminants. Although it had been present for
a long time when the type is limited, the problem was recently propagated
to nonlimited types because of an optimization.
While the fix is a one-liner, the change also makes it so that SS_Allocate
raises a Storage_Error when the size overflows, like the other allocators.
gcc/ada/
* exp_ch6.adb (Expand_Simple_Function_Return): Use a constant return
object when the simple return is rewritten as an extended one.
* libgnat/s-secsta.adb (SS_Allocate): Raise Storage_Error if the
requested size is negative.
* libgnat/s-secsta__cheri.adb (SS_Allocate): Likewise.
gcc/testsuite/
* gnat.dg/aggr35.adb: New test.
* gnat.dg/aggr35_pkg.ads, gnat.dg/aggr35_pkg.adb: New helper.
The documentation for Picolibc options was inserted at the top level
within the GCC options section. It really should be classified with
the target-specific options; that's where we document other options
specific to the runtime configuration, including MinGW, Darwin,
Gnu/Linux, etc.
The node name "Submodel Options" is not meaningful, and the section name
"Machine-Dependent Options" is misleading since this section also contains
subsections documenting options for the software environment on the target
as well as its hardware -- for example, Windows/Cygwin/MinGW, Darwin, etc.
"Target-Specific Options" is a better name for it as we already use that
phrasing elsewhere, e.g. "Target-Specific Attributes".
gcc/ChangeLog
* doc/extend.texi (Common Attributes): Fix cross-reference for
renamed "Submodel Options" -> "Target-Specific Options".
* doc/invoke.texi (Invoking GCC): Likewise for the menu.
(Option Summary): Likewise for the use here.
(Submodel Options): Rename to Target-Specific Options. Leave
an anchor with the old name. Add better index entries. Rewrite
introductory text.
(Precompiled Headers): Fix another cross-reference.
doc, i386: Document more CPUs as having CX16 support [PR107337]
The CX16 extension seems to have been omitted from the documentation
entries for a couple of early CPUs that supported it, which were
subsequently cut-and-pasted for newer models. I checked the code
against the list of CPUs in the issue and found one more (novalake)
affected CPU that was added since then.
gcc/ChangeLog
PR target/107337
* doc/invoke.texi (x86 Options): Add CX16 feature to nocona,
alderlake, arrowlake, arrowlake-s, pantherlake, novalake,
bonnell, sierraforest, grandridge, clearwaterforest, and amdfam10
family processors.
Richard Biener [Tue, 24 Mar 2026 18:09:38 +0000 (19:09 +0100)]
middle-end/121467 - split the Standard Pattern Names section
The following splits the standard pattern names section into two
(for now), listing vector related patterns separately. It also
adds a separate index for the many standard pattern names we have,
something long overdue.
* doc/gccint.texi: Add named pattern index with @mdindex.
* doc/md.texi (Standard Pattern Names For Generation): Split
table into two using subsections, splitting out vectorizer
related standard patterns. Use @mdindex for all standard
pattern names.
Roger Sayle [Sat, 4 Apr 2026 12:57:55 +0000 (13:57 +0100)]
PR c++/124573: ICE on invalid P4 regression
This patch addresses PR c++/124573 by making finish_enum_value_list more
robust to DECL_INITIAL being NULL, which I believe only occurs in the
event of an error, and treating it as integer_zero_node for the purposes
of error recovery.
2026-04-04 Roger Sayle <roger@nextmovesoftware.com>
gcc/cp/ChangeLog
PR c++/124573
* decl.cc (finish_enum_value_list): Defend against a DECL_INITIAL
being NULL during error recovery.
gcc/testsuite/ChangeLog
PR c++/124573
* g++.dg/other/enum4.C: New test case.
Jakub Jelinek [Sat, 4 Apr 2026 09:32:33 +0000 (11:32 +0200)]
c++: Implement CWG3119 - for-range-declaration of an expansion-statement as a templated entity
The following patch implements the proposed resolution of
https://wg21.link/cwg3119
Temporarily setting processing_template_decl around the
cp_parser_simple_declaration causes all kinds of ICEs and miscompilations,
this patch just sets in_expansion_stmt around it and allows the sb
pack in that case.
2026-04-04 Jakub Jelinek <jakub@redhat.com>
* parser.cc (cp_parser_expansion_statement): Temporarily set
in_expansion_stmt to true around cp_parser_simple_declaration
for range_decl.
(cp_parser_decomposition_declaration): Don't reject structured binding
packs if in_expansion_stmt is set.
libstdc++: Guard use of float16_t and bfloat16_t [PR124722]
The rest of this test is still relevant, thus only the (b)float16_t
tests are made optional rather than skipping the whole test via
dg-effective-target.
libstdc++-v3/ChangeLog:
PR libstdc++/124722
* testsuite/std/simd/traits_impl.cc: Add __STDCPP_FLOAT16_T__
and __STDCPP_BFLOAT16_T__ guards.
Jakub Jelinek [Sat, 4 Apr 2026 09:18:20 +0000 (11:18 +0200)]
c++: Partially implement mangling for C++26 pack indexing [PR124487]
I still haven't figured out how to correctly mangle the case
in pack-indexing9.C where write_type is called with PACK_INDEX_TYPE
where PACK_INDEX_PACK is TREE_VEC of types, i.e. already expanded pack,
but given that right now we sorry on mangling of all PACK_INDEX_TYPE
or PACK_INDEX_EXPR trees, I think the following patch is an incremental
progress in the right direction and just mangles what is clearly specified
in the proposal.
This patch relies on the PR124198 patch I've just posted, because the
casts to size_t change mangling of pack...[1] from having i1 in it
to m1 (on x86_64, j1 on ia32, ...).
2026-04-04 Jakub Jelinek <jakub@redhat.com>
PR c++/124487
* mangle.cc (write_type) <case PACK_INDEX_TYPE>: Handle pack index
mangling unless (for now) PACK_INDEX_PACK is a TREE_VEC.
(write_expression): Handle PACK_INDEX_EXPR.
* g++.dg/cpp26/pack-indexing7.C: Don't xfail dg-bogus.
* g++.dg/cpp26/pack-indexing22.C: New test.
Jakub Jelinek [Sat, 4 Apr 2026 09:07:40 +0000 (11:07 +0200)]
c++: Fix up pack indexing [PR124198]
https://eel.is/c++draft/expr.prim.pack.index#2 says:
The constant-expression shall be a converted constant expression of type
std::size_t whose value V, termed the index, is such that 0<=V<sizeof...(P).
But we actually don't implement it like that, instead just error out if
the index doesn't have an integral type or is negative.
Because of this we don't call mark_rvalue_use on it, so on pack-indexing20.C
we report a bogus warning that the var used in the index is unused but set,
and more importantly we reject the IMHO valid testcase pack-indexing21.C.
The following patch calls build_converted_constant_expr to make sure it
is converted, marked as read, if not possible to be converted diagnostics
is emitted.
2026-04-04 Jakub Jelinek <jakub@redhat.com>
PR c++/124198
* parser.cc (cp_parser_pack_index): If index is not type dependent,
call build_converted_constant_expr on it. Return error_mark_node
if index is error_operand_p.
* pt.cc (tsubst_pack_index): Likewise.
* g++.dg/cpp26/pack-indexing2.C (getT2, badtype4): Expect different
diagnostics.
* g++.dg/cpp26/pack-indexing20.C: New test.
* g++.dg/cpp26/pack-indexing21.C: New test.
xtensa: Change xtensa_legitimize_address() to allow the emission of one more ADDMI instruction
Previously, address displacement mitigation measures for exceeding machine
instruction limits involved using only one ADDMI machine instruction
(adding an immediate value that is a multiple of 256) to cover approxi-
mately 32 kilobytes before and after the address.
This patch expands the range covered by the mitigation by doubling it by
using just one more ADDMI instruction, slightly more advantageous than the
result without the mitigation, ie., covering the displacement amount by
loading from constant pool or using CONST16 instruction pair.
/* example */
int test(int a[]) {
return a[4] + a[16032];
}
* config/xtensa/xtensa.cc (xtensa_legitimize_address):
Add code to legitimize the displacement of 64 kilobytes before and
after using two ADDMI instructions.
xtensa: Small change to the alternative negsf2 pattern
The previously added alternative negsf2 pattern (for cases where both
source and destination are GP registers) directly specified multiple
machine instructions in the output template, but this patch replaces
that with an RTL representation using the split pattern, to increase
opportunities for instruction reordering.
gcc/ChangeLog:
* config/xtensa/xtensa.md (negsf2):
Change define_insn to define_insn_and_split, and replace the
corresponding output template with the split pattern.
Since the previous commit 6924c00c8710ec95834e21f8d68b10f2d09a8680 ("xtensa:
Make all memory constraints special"), it has been discovered that the
definition of TARGET_DIFFERENT_ADDR_DISPLACEMENT_P, which was previously
introduced to obtain appropriate memory reference displacements (commit 211459e12147e9ed42c0a0947b1b95b551e03ef3), is no longer necessary. In other
words:
- The order of the movsi_internal MD pattern alternatives has been re-
arranged so that memory references with shorter displacements take
precedence
- Furthermore, since all memory constraints are now "special," address
reload operations that explicitly add the displacement to the base
register and then adopt a 0-displacement reference are no longer
performed and are simply skipped
Therefore, this patch removes the definition of
TARGET_DIFFERENT_ADDR_DISPLACEMENT_P.
xtensa: Avoid redundant MEM_P() checks in memory constraint definitions
If the memory constraint definition includes (match_code "MEM"), then
the subsequent 'op' is undoubtedly MEM rtx, and all that remains is to
determine if 'XEXP (op, 0)' is the address corresponding to that
definition using (match_test "...").
This patch eliminates the need to call MEM_P() again in the predicate
function called from (match_test "...") in the memory constraint
definitions.
gcc/ChangeLog:
* config/xtensa/xtensa.cc (smalloffset_mem_p):
Rename it to smalloffset_address_p and remove the result check
of MEM_P().
(constantpool_address_p): Change from static scope to global.
* config/xtensa/xtensa-protos.h (smalloffset_mem_p):
Rename it to smalloffset_address_p.
(constantpool_address_p): New function prototype.
* config/xtensa/constraints.md (R):
Change the call in (match_test "...") from smalloffset_mem_p()
to smalloffset_address_p().
(T, U): Change the call in (match_test "...") from
constantpool_mem_p() to constantpool_address_p().
Harald Anlauf [Fri, 3 Apr 2026 20:35:48 +0000 (22:35 +0200)]
Fortran: fix resolution of generic interface with TYPE(C_PTR) [PR66973]
When symbols from the intrinsic module ISO_C_BINDING were USEd indirectly,
the resolution of generic interfaces with procedures having dummies with
TYPE(C_PTR) or TYPE(C_FUNPTR) could fail when the actual argument was
C_LOC() or C_FUNLOC(). Amend checking of actual versus formal procedure
arguments to these cases.
PR fortran/66973
gcc/fortran/ChangeLog:
* interface.cc (gfc_compare_actual_formal): Check that C_LOC and
C_FUNLOC from ISO_C_BINDING as actual argument are passed to a
dummy argument of matching type C_PTR/C_FUNPTR.
gcc/testsuite/ChangeLog:
* gfortran.dg/generic_36-1.f90: New test.
* gfortran.dg/generic_36-2.f90: New test.
doc, c: Clarify status of decimal floating point support [PR123234]
At first glance, the GCC manual's section documenting decimal floating
point support as a C extension appears to be bit-rotten, since this
feature is now standardized in ISO C23. In fact, though, GCC's
implementation is based on the older N1312 proposal, and full C23
support is not yet available. This patch makes the GCC manual say that
explicitly.
gcc/ChangeLog
PR c/123234
* doc/extend.texi (Decimal Float): Clarify that GCC really does
support only the older N1312 draft as documented here, not the
standard C23 functionality yet.
If the promise ctor throws, the EH cleanup will access refcount before
it is initialized. Initialize it to zero so that cleanups can take
place.
This seems very hard to hit on systems that ensure the stack starts
out zero-initialized, but on VxWorks in kernel mode, this hits more
often than not on various architectures.
Jakub Jelinek [Fri, 3 Apr 2026 18:55:26 +0000 (20:55 +0200)]
strlen: Fix up memcpy/strcpy/strcat handling [PR124754]
The following testcase ICEs because it tries to use a freed strinfo.
strinfo uses refcounting and vectors of pointers to those are either shared
in between bbs or unshared when some later bb needs to modify something.
The ICE is due to the second memcpy handling. Since r10-5451 it first
calls get_stridx on dst (&a), then get_strinfo with the returned index and
then get_stridx on src (&a + 24). &a has been referenced earlier and
the pass knows some details on its string length (let's ignore that the
testcase invokes UB for now, I think it can happen even on valid code,
just haven't managed to adjust the testcase, but supposedly the unreduced
original is valid), so the strinfo is shared with other bbs.
WHen get_stridx is called for &a + 24, it sees it doesn't know anything
about that yet and wants to create a strinfo for it. But related strinfos
are chained, so &a's next should be &a + 24 in this testcase, that means
we need to unshare the &a strinfo so that we can modify it while keeping
the one entry used by earlier bbs unmodified. The problem is that
handle_builtin_memcpy called get_strinfo before this, so it got hands on
the old still not unshared strinfo for &a and because it isn't refreshed
after the get_stridx call by another get_strinfo call, we try to unshare
it again and break the refcounting.
So, basically for calls which call get_stridx twice, we need top make sure
we do both get_stridx calls before the first get_strinfo call, or repeat
get_strinfo after the second get_stridx call.
In handle_builtin_memcpy it used to be right and got broken by r10-5451,
but I'm in strcpy/strcat handling I've screwed it up since the pass was
added.
Fixed thusly.
2026-04-03 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/124754
* tree-ssa-strlen.cc (strlen_pass::handle_builtin_strcpy): Make
sure both get_stridx calls are done before first get_strinfo call.
(strlen_pass::handle_builtin_memcpy): Likewise.
(strlen_pass::handle_builtin_strcat): Likewise.
* g++.dg/tree-ssa/strlenopt-3.C: New test.
Reviewed-by: Jeffrey Law <jeffrey.law@oss.qualcomm.com>
Jakub Jelinek [Fri, 3 Apr 2026 18:46:42 +0000 (20:46 +0200)]
c++, libstdc++: Attempt to implement P3842R2 - A conservative fix for constexpr uncaught_exceptions() and current_exception()
The following patch attempts to implement the
P3842R2 - A conservative fix for constexpr uncaught_exceptions()
and current_exception()
paper. std::current_exception() and std::uncaught_exceptions() aren't
constexpr anymore (admittedly, they weren't declared that way in the
headers before either, but the FE magically treated them as such),
instead two new FE builtins are introduced so that one can get their
behavior before this patch when needed. So, at constant evaluation
time they are constant evaluated and if they are not folded away,
they are transformed into std::current_exception() or
std::uncaught_exceptions() runtime calls during gimplification.
And nested_exception isn't constexpr anymore either.
2026-04-03 Jakub Jelinek <jakub@redhat.com>
gcc/cp/
* cp-tree.h (enum cp_built_in_function): Add
CP_BUILT_IN_CURRENT_EXCEPTION and CP_BUILT_IN_UNCAUGHT_EXCEPTIONS.
* tree.cc (builtin_valid_in_constant_expr_p): Handle
those.
* decl.cc (cxx_init_decl_processing): Build
decls for CP_BUILT_IN_CURRENT_EXCEPTION and
CP_BUILT_IN_UNCAUGHT_EXCEPTIONS.
(require_deduced_type): Deduce CP_BUILT_IN_CURRENT_EXCEPTION
return type.
* cp-gimplify.cc (cp_gimplify_expr): Handle
CP_BUILT_IN_CURRENT_EXCEPTION and CP_BUILT_IN_UNCAUGHT_EXCEPTIONS.
* constexpr.cc (enum cxa_builtin): Remove STD_UNCAUGHT_EXCEPTIONS
and STD_CURRENT_EXCEPTION, add BUILTIN_UNCAUGHT_EXCEPTIONS and
BUILTIN_CURRENT_EXCEPTION, renumber some enumerators.
(cxx_cxa_builtin_fn_p): Don't check for std::uncaught_exceptions
nor std::current_exception.
(cxx_eval_cxa_builtin_fn): Handle BUILTIN_UNCAUGHT_EXCEPTIONS
and BUILTIN_CURRENT_EXCEPTION instead of STD_UNCAUGHT_EXCEPTIONS
and STD_CURRENT_EXCEPTION.
(cxx_eval_builtin_function_call): Handle
CP_BUILT_IN_CURRENT_EXCEPTION and CP_BUILT_IN_UNCAUGHT_EXCEPTIONS.
Do just one fndecl_builtin_p check for BUILT_IN_FRONTEND and
switch on DECL_FE_FUNCTION_CODE.
gcc/testsuite/
* g++.dg/cpp26/constexpr-eh3.C: Use __builtin_current_exception()
instead of std::current_exception() and
__builttin_uncaught_exceptions() instead of
std::uncaught_exceptions(). Remove nested_exception related parts
of the test.
* g++.dg/cpp26/constexpr-eh8.C: Use __builtin_current_exception()
instead of std::current_exception().
libstdc++-v3/
* libsupc++/exception_ptr.h (std::make_exception_ptr): Use
__builtin_current_exception() instead of current_exception() if
the builtin exists.
* libsupc++/nested_exception.h: Revert 2026-01-07 and 2025-07-10
changes.
* testsuite/18_support/exception_ptr/exception_ptr_cast.cc (test01):
Use __builtin_current_exception instead of std::current_exception
if __has_builtin(__builtin_current_exception). Otherwise don't
try to constant evaluate test01.
Reviewed-by: Jason Merrill <jason@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
doc: Improve documentation of -Wchar-subscripts and char signedness [PR94182]
The documentation of -Wchar-subscripts was missing cross-references to
discussion elsewhere in the manual about how the char type may be either
signed or unsigned. Besides adding the references, I've also done some
improvements to those two other sections.
gcc/ChangeLog
PR other/94182
* doc/implement-c.texi (Characters implementation): Add
cross-reference to more detailed discussion about signedness.
* doc/invoke.texi (C Dialect Options): Combine -fsigned-char
and -funsigned-char table entries since the following discussion
applies to both. Add an anchor so other things can point at it.
(Warning Options): Add cross-references to the above two places.
Clarify that the warning is given regardless of whether char is
signed or unsigned.
Harald Anlauf [Wed, 1 Apr 2026 20:28:02 +0000 (22:28 +0200)]
Fortran: fix passing a procedure pointer to c_funloc [PR124652]
PR fortran/124652
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_conv_procedure_call): Do not clobber a
procedure pointer intent(out) argument.
* trans-intrinsic.cc (conv_isocbinding_function): When passing to
C_FUNLOC a procedure pointer that is a dummy, dereference it.
Jakub Jelinek [Fri, 3 Apr 2026 08:29:51 +0000 (10:29 +0200)]
c++: Implement LWG4517 - data_member_spec should throw for cv-qualified unnamed bit-fields
As written in https://wg21.link/lwg4517 , unnamed bit-fields shall not
be declared with cv-qualified types, so the following patch rejects it
when trying to create that in data_member_spec.
2026-04-03 Jakub Jelinek <jakub@redhat.com>
* reflect.cc (eval_data_member_spec): Implement C++26 LWG4517
- data_member_spec should throw for cv-qualified unnamed bit-fields.
* g++.dg/reflect/data_member_spec2.C: Add tests for unnamed bit-fields
with const and/or volatile types.
Jakub Jelinek [Fri, 3 Apr 2026 08:26:31 +0000 (10:26 +0200)]
testsuite: Add testcase for LWG4556 - Unclear properties of reflection strings
The issue clarifies what the *string_view points to is not valid for
template arguments with pointer type, the following testcase verifies
that we already reject it.
Jakub Jelinek [Fri, 3 Apr 2026 08:18:25 +0000 (10:18 +0200)]
c++: Handle RAW_DATA_CST and RANGE_EXPR in build_vec_init [PR124531]
The following testcases show two bugs in build_vec_init, one
introduced with either since my r15-5958 (when using #embed) or
my r15-6339 (when not using it but large init transformed into
RAW_DATA_CST), problem that the FOR_EACH_CONSTRUCTOR_ELT loop
in build_vec_init doesn't handle RAW_DATA_CST, and another since
Marek's r15-7810 which has added limited RANGE_EXPR support to that loop,
but only changed the num_initialized_elts value computation and
has not actually also added a runtime loop over the range to initialize
multiple elements to the same value. The lack of RAW_DATA_CST handling
causes ICEs (during expansion or later on), while the lack of proper
RANGE_EXPR handling causes wrong-code.
The following patch attempts to fix both.
RAW_DATA_CST has 2 separate variants of handling it, one is when
the types match (digested is true) and it is char/signed char/unsigned
char/std::byte array, in that case (especially if it is huge initializer,
but RAW_DATA_CST already implies 62+ elements) it emits a setting of
MEM_REF with ARRAY_TYPE for the RAW_DATA_LENGTH bytes to a CONSTRUCTOR
with the RAW_DATA_CST in it which gimplifier handles (but of course for
try_const const_vec it uses the RAW_DATA_CST directly).
The second variant is for other types or non-digested one, in that case
RAW_DATA_CST is peeled appart into individual INTEGER_CSTs.
As for RANGE_EXPR, for try_const const_vec it uses the RANGE_EXPR field
as before, but for the runtime code it puts the
one_init/base increment/iterator decrement stmts into a loop which iterates
range_expr_nelts times.
The reason for the first hunk is to optimize the CONSTRUCTOR from what
the preprocessor emits, i.e.
CPP_NUMBER CPP_COMMA CPP_EMBED CPP_COMMA CPP_NUMBER
turned into
INTEGER_CST RAW_DATA_CST INTEGER_CST
into just RAW_DATA_CST covering also the first and last number.
I'm worried about braced_lists_to_strings transformation to STRING_CST
when try_const though, I think it isn't handled right now, so the code
ignores STRING_CST return.
2026-04-03 Jakub Jelinek <jakub@redhat.com>
PR c++/124531
* init.cc (build_vec_init): Call braced_lists_to_strings for
array CONSTRUCTORs. Handle RAW_DATA_CST and handle RANGE_EXPR
correctly.
* g++.dg/cpp/embed-29.C: New test.
* g++.dg/cpp0x/pr124531.C: New test.
Paul Thomas [Thu, 2 Apr 2026 09:00:37 +0000 (10:00 +0100)]
Fortran: Regression in gfc_convert_to_structure_constructor
This patch is not the prettiest because it jumps across the normal
wrapping up of the actual arguments in gfc_conv_procedure_call. However
the alternatives, which required jumps past existing call and the logic
for adding the pre and post blocks looked even uglier. The testcase has
been checked with valgrind and does not cause memory leaks. The memory
leaks in pr105168, mentioned in this pr, are fixed too.
2026-04-02 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/100155
* trans-expr.cc (gfc_add_interface_mapping): 'new_sym' dummy
attribute set to zero.
(gfc_conv_procedure_call): Deallocate allocatable components of
a class argument, enclosed in parentheses,wrap up the parmse
and proceed to the next argument.
gcc/testsuite/
PR fortran/100155
* gfortran.dg/pr100155.f90: New test.
Nathaniel Shead [Sat, 14 Mar 2026 14:58:41 +0000 (01:58 +1100)]
c++/modules: Propagate DECL_ARGUMENTS when reading a function def [PR124477]
The crash in the given PR occurs because we've streamed the definition
of an anticipated builtin, but when processing the nonnull attribute we
find that its DECL_ARGUMENTS is null.
Back in r14-8196-g3471a61ed0ddef70de8f1bbba85cd1e945fc86fd I removed the
setting of DECL_ARGUMENTS as this was causing issues where we were
replacing the argument list for existing definitions. This was because
the definition we streamed was referencing those same PARM_DECLs, and if
they diverged we got different parts of the body with different
pointers to the same logical parameter.
In most cases we do not need to adjust DECL_ARGUMENTS because
fn_parms_fini will substitute in the correct DECL_ARGUMENTS from the
existing declaration. But if DECL_ARGUMENTS was not set on the existing
declaration at all, as happens with e.g. anticipated builtins, then we
do need to set them.
PR c++/124477
gcc/cp/ChangeLog:
* module.cc (trees_in::read_function_def): Set DECL_ARGUMENTS if
installing and otherwise missing.
gcc/testsuite/ChangeLog:
* g++.dg/modules/builtin-10_a.C: New test.
* g++.dg/modules/builtin-10_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Control FLow Graph complexity exploded because of indirect jumps. Those
have been replaced with SWITCH_EXPR.
A number of calls to gg_get_address_of() have been replaced with
gg_pointer_to_array() so that we properly get a pointer to the first element
of arrays, rather than a pointer to an array object.
The speed of the INSPECT (Format 1) STATEMENT has been improved by breaking
out a faster routine when the character set is single-byte-coded, like
ASCII or EBCDIC.
A number of COBOL variables were improperly allocated as executable globals.
They are now allocated as per-function static variables for top-level
COBOL program-ids.
gcc/cobol/ChangeLog:
* cobol1.cc (cobol_langhook_handle_option): Handle OPT_Wrecording_mode.
* gcobol.1: Documentation of pre-program registers.
* genapi.cc (hijacker): Define new function hijacked code generation.
(RETURN_WHEN_HIJACKED): Macro for wrapping if(hijacked)return;
(hijacked): Either a boolean or false depending on ENABLE_HIJACKING.
(set_exception_environment): Use gg_pointer_to_array instead of
gg_get_address_of.
(parser_statement_end): Formatting.
(section_label): Change ALTER STATEMENT processing.
(pseudo_return_push): Expand TRACE1 message.
(pseudo_return_pop): Expand TRACE1 message; improved PERFORM processing.
(find_procedure): Change how cbl_proc_t is allocated; improved PERFORM
processing.
(parser_enter_section): Changed ALTER statement processing.
(parser_enter_paragraph): Likewise.
(parser_goto): Use SWITCH_EXPR instead of indirect jump.
(parser_perform): Likewise.
(internal_perform_through): Likewise.
(parser_enter_file): Use SWITCH_EXPR for implementing ENTRY statement.
(parser_leave_file): Build table of values for the SWITCH_EXPR.
(enter_program_common): Remove unused JMP *ptr.
(parser_enter_program): Code to hijack code generation for a function
"dubner" when ENABLE_HIJACKING is defined.
(build_dispatch_switch): Generalize builder of SWITCH_EXPR.
(build_alter_switch): Uses build_dispatch_switch.
(build_entry_switch): Likewise.
(build_perform_dispatcher): Likewise.
(parser_end_program): Wrap build_perform_dispatcher() in if(!hijacked).
(parser_init_list): Use RETURN_WHEN_HIJACKED; use gg_pointer_to_array()
instead of gg_get_address_of().
(psa_FldLiteralN): Set TREE_READONLY(var_decl) = 1.
(parser_alphabet): use gg_pointer_to_array() instead of
gg_get_address_of().
(parser_assign): Formatting.
(program_end_stuff): Call hijacking() when ENABLE_HIJACKING and the
program-id is "hijack"; use gg_pointer_to_array().
(parser_exit): Handle if(hijacked);
(register_find): New static function to find XML-* COBOL variables.
(parser_xml_parse): Updated XML PARSE statement handling.
(initialize_the_data): Use RETURN_WHEN_HIJACKED.
(establish_using): Change first-time-through processing.
(parser_division): Change ENTRY statement processing.
(parser_see_stop_run): Changed RETURN-CODE per-function variable
processing.
(parser_label_label): Use RETURN_WHEN_HIJACKED.
(parser_label_goto): Likewise.
(parser_perform_inline_times): Honor cbl_field_t offset for the count
parameter.
(inspect_tally): Use __gg__inspect_format_1_sbc() for SBC characters.
(create_and_call): Use per-function RETURN-CODE.
(parser_entry_activate): Eliminate static tree variables.
(parser_entry): Use automatic tree variables.
(parser_program_hierarchy): Use RETURN_WHEN_HIJACKED and
gg_pointer_to_array().
(build_temporaryN): New function compiled when ENABLE_HIJACKING.
(hijack_for_development): Changed to generate minimal GENERIC.
(actually_create_the_static_field): Use gg_structure_type_constructor
to create the constructor for the static cblc_field_t VAR_DECL.
(psa_FldLiteralA): Move where TREE attributes are established.
(parser_local_add): Use gg_pointer_to_array().
(parser_symbol_add): Use RETURN_WHEN_HIJACKED(); use gg_pointer_to_array().
* gengen.cc (gg_append_statement): #if 0 around some debugging code.
(gg_show_type): Expanded to display "static" and "readonly".
(gg_find_field_in_struct): Moved and rewritten.
(gg_get_structure_type_decl): New function.
(gg_start_building_a_union): Eliminated.
(gg_start_building_a_struct): Eliminated.
(gg_add_field_to_structure): Eliminated.
(gg_structure_type_constructor): New function.
(gg_get_struct_type_decl): Eliminated.
(gg_get_union_type_decl): Eliminated.
(gg_get_local_struct_type_decl): Eliminated.
(gg_get_filelevel_struct_type_decl): Eliminated.
(gg_get_filelevel_union_type_decl): Eliminated.
(gg_define_local_struct): Eliminated.
(gg_assign_to_structure): Eliminated.
(gg_define_array): Formatting.
(gg_pointer_to_array): Returns ADDR_EXPR for &array[0];
(gg_goto): Comment reflecting why we aren't using it.
* gengen.h (SHORT_P): Alias for build_pointer_type(short_integer_type_node);
(struct gg_function_t): Changes mostly in support of SWITCH_EXPR.
(gg_get_local_struct_type_decl): Eliminated declaration.
(gg_get_filelevel_struct_type_decl): Likewise.
(gg_get_filelevel_union_type_decl): Likewise.
(gg_define_local_struct): Likewise.
(gg_get_structure_type_decl): New declaration.
(gg_structure_type_constructor): New declaration.
(gg_assign_to_structure): Eliminated declaration.
(gg_define_uchar_star): Changed declaration.
(gg_pointer_to_array): New declaration.
* genutil.cc: Removed unused globals; added var_decl_entry_index.
* genutil.h: Likewise.
* parse.y: Change program-id and REDEFINES handling.
* parse_ante.h: Likewise.
* scan_ante.h (is_refmod): Rewrite.
* structs.cc (create_cblc_field_t): Use gg_get_structure_type_decl().
* symbols.cc (return_code_register): Use per-program COBOL registers.
(symbol_redefines_root): New function.
(symbols_update): Use per-program COBOL registers.
(symbol_table_init): Implement per-program registers.
(symbol_registers_add): Likewise.
(cbl_field_t::encode): Loosen COBOL level requirement.
* symbols.h (struct cbl_proc_t): SWITCH_EXPR-based PERFORM returns.
(symbol_redefines_root): New declaration.
(symbol_registers_add): New declaration.
(new_alphanumeric): New comment.
* util.cc (FOR_JIM): Remove some unused demonstration code.
(cbl_field_t::encode_numeric): Likewise.
libgcobol/ChangeLog:
* Makefile.am: Include new libgcobol/inspect.cc file.
* Makefile.in: Likewise.
* charmaps.h: Remove global RETURN-CODE
* constants.cc (struct cblc_field_t): Eliminate various globals.
* gcobolio.h: Eliminate cblc_field_t::dummy member.
* libgcobol.cc (funky_find): Moved to inspect.cc.
(funky_find_wide): Likewise.
(funky_find_backward): Likewise.
(funky_find_wide_backward): Likewise.
(normalize_id): Likewise.
(match_lengths): Likewise.
(the_alpha_and_omega): Likewise.
(the_alpha_and_omega_backward): Likewise.
(inspect_backward_format_1): Likewise.
(__gg__inspect_format_1): Likewise.
(inspect_backward_format_2): Likewise.
(__gg__inspect_format_2): Likewise.
(normalize_for_inspect_format_4): Likewise.
(__gg__inspect_format_4): Likewise.
(__gg__is_canceled): Simplify establishing the function return code.
(__gg__pseudo_return_push): Work with integer indexes rather than
addresses.
(__gg__set_data_member): New function.
* xmlparse.cc (xml_event): Use passed variables rather than globals.
(__gg__xml_parse): Likewise.
* inspect.cc: New file.
Andrew Pinski [Wed, 18 Mar 2026 00:13:55 +0000 (17:13 -0700)]
testsuite/c++: Fix lifetime issue in func-params-07.C [PR124548]
So compiling this testcase with -fsantize=address we get an use
after the lifetime is gone. In this case it is the rvalue reference
argument to my_coro. With more inlining into main, this testcase
started to fail at -O3 as we remove the store to the temporary now
as the access is after the lifetime of the temporary has ended.
The best way of fixing this is creating an rvalue reference that will
then forward into the argument. This means we have the rvalue reference
no longer as a temporary that ends at the end of the statement but rather
end of the scope (since it is extended).
Tested on x86_64-linux-gnu with the testcase now passing at -O3.
PR testsuite/124548
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/torture/func-params-07.C (main): Fix lifetime
issue of rvalue reference.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Marek Polacek [Wed, 1 Apr 2026 20:06:58 +0000 (16:06 -0400)]
c++/reflection: fix wrong-code with members_of [PR124646, PR124645]
My r16-8235 change should have set DECL_EXTERNAL only in the
!at_function_scope_p block, before rest_of_decl_compilation. Setting
DECL_EXTERNAL on the temporary var for both at_function_scope_p and
!at_function_scope_p cases causes issues: in members_of11.C, we wrongly
initialize 'mem' in the loop to A::a both times, insted of A::a and B::b.
Similarly in members_of12.C we wrongly initialize member when inspecting
ns2.
I couldn't track down where *exactly* things go wrong, but the point
of r16-8235 was to set DECL_EXTERNAL only for the rest_of_decl_compilation
call.
PR c++/124646
PR c++/124645
gcc/cp/ChangeLog:
* call.cc (set_up_extended_ref_temp): Move setting DECL_EXTERNAL
to the !at_function_scope_p block.
gcc/testsuite/ChangeLog:
* g++.dg/reflect/members_of11.C: New test.
* g++.dg/reflect/members_of12.C: New test.
Tomasz Kamiński [Thu, 2 Apr 2026 10:00:01 +0000 (12:00 +0200)]
libstdc++: Updated inplace_vector::try_ functions per P3981R2 and P4022R0.
This paper removes the try_append_range from inplace_vector and changes the
return type of try_emplace_back and try_push_back to optional<_Tp&> per:
P4022R0: Remove try_append_range from inplace_vector for now.
P3981R2: Better return types in std::inplace_vector and std::exception_ptr_cast.
The test are also expanded to cover type Y, that is convertible to optional<Y&>,
and require return type to be constructed using in_place.
libstdc++-v3/ChangeLog:
* include/bits/version.def (inplace_vector): Bump to 202603.
* include/bits/version.h: Regenerate.
* include/std/inplace_vector (inplace_vector::try_emplace_back)
(inplace_vector::try_push_back): Change return type to optional<_Tp&>
and adjust implementation accordingly.
(inplace_vector::try_append_range): Remove.
* include/debug/inplace_vector (inplace_vector::try_emplace_back)
(inplace_vector::try_push_back, inplace_vector::try_append_range):
Likewise.
* testsuite/23_containers/inplace_vector/modifiers/single_insert.cc:
Updated check for the optional<T&> return. Added test for type
convertible to optional<T&>
* testsuite/23_containers/inplace_vector/debug/invalidation/try_emplace_back.cc:
Use has_value() to check if engaged optional is returned.
* testsuite/23_containers/inplace_vector/debug/invalidation/try_push_back.cc:
Likewise.
* testsuite/23_containers/inplace_vector/modifiers/multi_insert.cc:
Remove try_append_range tests.
* testsuite/23_containers/inplace_vector/debug/invalidation/try_append_range.cc:
Removed.
* testsuite/23_containers/inplace_vector/version.cc: Updated expected
feature test macro value.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
r16-5555-g952e145796da0f introduced a problem for aggregates.
Allowing speculating non-trapping loads is ok but allowing
speculating non-trapping aggregate copies is not valid as
there is no ssa renaming for the lhs. So for aggregates,
we need to treat it similar as a trapping load to find if
it is speculating. Since we already reject 'delayed' loads
for aggregates, we will skip over this load.
Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/124746
gcc/ChangeLog:
* tree-ssa-phiprop.cc (propagate_with_phi): Treat
and aggregate copy as it is a trapping load.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr124746-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Andrew Pinski [Wed, 1 Apr 2026 17:35:57 +0000 (10:35 -0700)]
phiprop: Move the check for load of ptr before the checks of dom
This moves the check for thge load of *ptr before the checks of domination.
In the next patch I need to know if the load is an aggregates or not.
This should NOT have any code generation difference.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-ssa-phiprop.cc (propagate_with_phi): Move the
check for load from ptr before the checks of domination.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
projects / thirdparty / gcc.git / log
