Gaius Mulley [Tue, 21 Apr 2026 01:56:39 +0000 (02:56 +0100)]
PR modula2/120189 Bugfix to documentation and fix prototypes in m2rts.h
This patch rewrites the Building a shared library section in the
gm2.texi. The new content addresses the default dynamic module
scaffold and also provides an example of C++ calling the m2 shared
library. Bootstrapped using lto on amd64.
gcc/ChangeLog:
PR modula2/120189
* doc/gm2.texi (Building a shared library): Rewrite.
d: Fix ICE in must_pass_in_stack_var_size_or_pad with D enums [PR123411]
An `enum : enum A` type caused the already computed underlying type size
of `enum A` to be overwritten with NULL_TREE. To fix, don't finish the
enum with layout_type unless we're handling the main variant type.
PR d/123411
gcc/d/ChangeLog:
* types.cc (TypeVisitor::visit (TypeEnum *)): Only call layout_type on
the TYPE_MAIN_VARIANT of the enum.
Jason Merrill [Mon, 20 Apr 2026 16:45:57 +0000 (12:45 -0400)]
c++: std::optional reset and constexpr [PR124910]
Constant evaluation didn't recognize that destroying _M_value made it no
longer the active member of the anonymous union, so we were treating the
result as containing an out-of-lifetime value. Instead we should treat the
union as no longer having an active member.
PR c++/124910
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_store_expression): Ending the
lifetime of the active member means no active member.
The switch to front-end lowering of AA literals regressed on 32bit SPARC
targets, as the runtime function `_d_assocarrayliteralTX()` returns a
`void*`, but the expression should be of type `struct { void* ptr; }`.
PR d/124157
gcc/d/ChangeLog:
* expr.cc (ExprVisitor::visit (AssocArrayLiteralExp *)): Return AA
constructor with memory returned by _d_assocarrayliteralTX().
Marek Polacek [Fri, 17 Apr 2026 16:45:53 +0000 (12:45 -0400)]
c++/reflection: support splices with CTAD [PR124706]
This PR points out that we don't handle a splice-type-spec that
designates a deducible template, which then serves as a placeholder
for CTAD. This is allowed by [dcl.type.simple]/3. This patch
fixes that problem by calling make_template_placeholder if we
get a deducible template.
c++, contracts: Account for lambda captures in pre/post [PR124648].
When we have lambda captures, they appear in the vars slot of a bind
expression at the outer operator() body.
We need these to be visible for any pre or post conditions that might
use them, therefore (when a lambda has captures) nest the application
of contract pre and post conditions within the lambda outer bind
expressino.
PR c++/124648
gcc/cp/ChangeLog:
* contracts.cc (maybe_apply_function_contracts): Nest pre and
post conditions inside the outer bind expression of a lambda
with captures.
gcc/testsuite/ChangeLog:
* g++.dg/contracts/cpp26/expr.prim.lambda.closure.p10.C: Update
to include tests of conditions seen in PR124648.
Marek Polacek [Fri, 17 Apr 2026 21:09:43 +0000 (17:09 -0400)]
c++/reflection: dependent type considered consteval-only [PR124855]
Here we emit the "function of consteval-only type must be declared
'consteval'" error for f, even though its type will become
char f(int) after substitution, which is not consteval-only. We
probably shouldn't consider dependent type consteval-only.
PR c++/124855
gcc/cp/ChangeLog:
* reflect.cc (consteval_only_p): Return false if the type is
dependent.
Jonathan Wakely [Fri, 17 Apr 2026 20:53:16 +0000 (21:53 +0100)]
libstdc++: Fix accidentally committed change to spelling of macro
This change to the macro was done intentionally to quickly test that the
changes in r16-8720-g209550a04e143e did not break the code in the #else
branch, but it was not supposed to be committed!
Jakub Jelinek [Mon, 20 Apr 2026 07:53:38 +0000 (09:53 +0200)]
testsuite: Remove -m32 from gcc.target/i386 test [PR122021]
I found another test which uses -m32 in gcc.target/i386/ . Similarly
to the previously fixed tests, the test ought to be tested during i686-linux
testing or x86_64-linux test with --target_board=unix\{-m32,-m64\}
There is nothing ia32 specific on the test, so I've just dropped the -m32.
See also r13-143, r13-6846, r15-7748 and r15-7749 for similar changes in the
past.
2026-04-20 Jakub Jelinek <jakub@redhat.com>
PR middle-end/122021
* gcc.target/i386/pr122021-0.c: Remove -m32 from dg-options.
H.J. Lu [Mon, 20 Apr 2026 05:02:10 +0000 (13:02 +0800)]
pr121649.c: Replace long with long long
pr121649.c is a test enabled for int128 targets. It assumes that long
is 64-bit, which isn't true for all int128 targets. Replace long with
long long for 64-bit integer.
PR testsuite/124939
* gcc.dg/torture/pr121649.c: Replace long with long long.
Jakub Jelinek [Mon, 20 Apr 2026 07:11:24 +0000 (09:11 +0200)]
bitintlower: Padding bit fixes, part 3 [PR123635]
I've debugged the rest of the failures on riscv64-linux (in particular
torture/bitint-{87,89}.c FAILs at -O2).
This is on top of https://gcc.gnu.org/pipermail/gcc-patches/2026-April/713242.html
patch.
One problem was that the lower_shift_stmt RSHIFT_EXPR change to iterate
until p2 rather than p (where p2 is p + 1 if bitint_ext_full and there is
full limb of padding bits), the loop is emitted with a condition before the
header and another condition before the latch edge and I've mistakenly fixed
just the latter and not the former.
ANother problem was that in all the 3 RSHIFT_EXPRs added meant to set
a full limb to 0 or all ones based on most significant bit I've mistakenly used
unsigned type rather than signed, so it was set to 0 or 1 instead (this
was twice in lower_shift_stmt, for the LSHIFT_EXPR case in both cases and
once in lower_float_conv_stmt).
And finally, because unsigned MULT_EXPR doesn't have overflow undefined, we
actually don't need to just clear the full padding bit limb (if any) but
even the padding bits in the partial limb (if any; and this actually doesn't
affect just arm and riscv, but also affects s390x and loongarch).
2026-04-20 Jakub Jelinek <jakub@redhat.com>
PR middle-end/123635
* gimple-lower-bitint.cc (bitint_large_huge::lower_shift_stmt): In the
RSHIFT_EXPR case, use p2 in two LE_EXPR conditions rather than just
one. In LSHIFT_EXPR case, use signed RSHIFT_EXPR instead of unsigned.
(bitint_large_huge::lower_muldiv_stmt): For unsigned MULT_EXPR with
bitint_extended if prec is not multiple of limb_prec, clear padding
bits after libgcc call.
(bitint_large_huge::lower_float_conv_stmt): Use signed RSHIFT_EXPR
instead of unsigned.
Reviewed-by: Jeffrey Law <jeffrey.law@oss.qualcomm.com>
Jakub Jelinek [Mon, 20 Apr 2026 07:08:49 +0000 (09:08 +0200)]
bitintlower: Padding bit fixes, part 2 [PR123635]
So, I've tried the (extremely slow) cfarm95 RISCV box and found that my
earlier PR123635 patch actually broke stuff.
First thing I found is that __riscv__ macro I was using in bitintext.h
doesn't exist and fixed that.
I wrote two new tests (88/89, one for a problem I'll talk about later and
one to cover shifts) and fixed one nit in 86/87. All the testing
has been done on this modified tests and using
make -j8 -k check-gcc RUNTESTFLAGS="dg.exp='*bitint* pr112673.c builtin-stdc-bit-*.c pr112566-2.c pr112511.c pr116588.c pr116003.c pr113693.c pr113602.c flex-array-counted-by-7.c' dg-torture.exp='*bitint* pr116480-2.c pr114312.c pr114121.c' dfp.exp=*bitint* vect.exp='vect-early-break_99-pr113287.c' tree-ssa.exp=pr113735.c"
On pre-r16-8678 source, the FAILs were
FAIL: gcc.dg/torture/bitint-82.c -O0 execution test
FAIL: gcc.dg/torture/bitint-82.c -O2 execution test
FAIL: gcc.dg/torture/bitint-83.c -O0 execution test
FAIL: gcc.dg/torture/bitint-83.c -O2 execution test
FAIL: gcc.dg/torture/bitint-86.c -O0 execution test
FAIL: gcc.dg/torture/bitint-86.c -O2 execution test
FAIL: gcc.dg/torture/bitint-87.c -O0 execution test
FAIL: gcc.dg/torture/bitint-87.c -O2 execution test
FAIL: gcc.dg/torture/bitint-88.c -O0 execution test
FAIL: gcc.dg/torture/bitint-88.c -O2 execution test
FAIL: gcc.dg/torture/bitint-89.c -O0 execution test
FAIL: gcc.dg/torture/bitint-89.c -O2 execution test
i.e. all the bitintext.h tests for padding bits (except bitint-84.c),
plus gcc.dg/bitint-39.c gcc.dg/torture/bitint-37.c tests timing out
(but those timed out due to extremely slow CPU all the time, and are
really large and not padding related, so let's ignore that).
Now, with r16-8678 (i.e. vanilla trunk), the FAILs are
FAIL: gcc.dg/torture/bitint-42.c -O0 execution test
FAIL: gcc.dg/torture/bitint-42.c -O2 execution test
FAIL: gcc.dg/torture/bitint-62.c -O0 execution test
FAIL: gcc.dg/torture/bitint-62.c -O2 execution test
FAIL: gcc.dg/torture/bitint-66.c -O0 execution test
FAIL: gcc.dg/torture/bitint-68.c -O0 execution test
FAIL: gcc.dg/torture/bitint-68.c -O2 execution test
FAIL: gcc.dg/torture/bitint-79.c -O2 execution test
FAIL: gcc.dg/torture/bitint-80.c -O2 execution test
FAIL: gcc.dg/torture/bitint-81.c -O0 execution test
FAIL: gcc.dg/torture/bitint-81.c -O2 execution test
FAIL: gcc.dg/torture/bitint-83.c -O2 execution test
FAIL: gcc.dg/torture/bitint-87.c -O2 execution test
FAIL: gcc.dg/torture/bitint-88.c -O2 execution test
FAIL: gcc.dg/torture/bitint-89.c -O2 execution test
So, I broke some tests (42, 62, 66, 68, 79, 80, 81) and
fixed a few too (82, 86 and at -O0 only 83, 87, 88, 89).
I've debugged the regressions I've caused and the problem is on large/huge
_BitInt bit-field stores, we can't clear any padding bits in those cases,
bit-fields never have paddings (C FE rejects oversized bit-fields and the
padding is used for further fields or is merely structure padding rather
than padding of the bit-field).
The following patch fixes more than that. There is another problem
(bitint-88.c tries to test that), when we merge some operation (e.g.
addition) of some narrower large/huge _BitInt with sign extension from
it into a wider unsigned _BitInt (e.g. signed _BitInt(513) addition
sign extended into unsigned _BitInt(1025)), the earlier solution for
the extra padding limb doesn't work properly, we do want to sign
extend the bit 512 into bits 513-1024, but the padding bits above
that need to be cleared. For the limb containing bit 1024 we do it
right, it is sign extension but outside of loop, so should cast the
all zeros or all ones value to unsigned long : 1 and back, but
the limb containing bit 1088 needs to be just zeroed.
And the patch also adds the bitint_ext_full handling to RSHIFT_EXPR
and LSHIFT_EXPR code.
With this, the FAILs on riscv64-linux are
FAIL: gcc.dg/torture/bitint-87.c -O2 execution test
FAIL: gcc.dg/torture/bitint-89.c -O2 execution test
which means I need to debug further the multiplication/division/modulo/
casts from float and there is some remaining problem with the shifts.
Plus something not covered yet, the overflow builtins/ubsan (all of +-*).
In any case, because this patch doesn't regress on riscv64-linux any
actual non-padding tests and even these two aren't regressions, I'd
like to commit this patch separately and fix stuff incrementally,
to unbreak the bit-field stores.
2026-04-20 Jakub Jelinek <jakub@redhat.com>
PR middle-end/123635
* gimple-lower-bitint.cc (bitint_precision_kind): Assert the current
assumptions, that bitint_ext_full for abi_limb_prec > limb_prec is
supported only when abi_limb_prec is limb_Prec * 2 and it is not
big endian in that case.
(bitint_large_huge::lower_mergeable_stmt): Don't set separate_ext
fir bitint_ext_full for bit-field stores. Guard the condition
on an extra limb of padding bits to be extended rather than including
earlier extensions in that too. If already sign extending before
and type is unsigned, set zero_ms_limb instead and later handle it.
(bitint_large_huge::lower_shift_stmt): Handle bitint_ext_full.
* gcc.dg/bitintext.h: Use __riscv macro instead of __riscv__.
* gcc.dg/torture/bitint-86.c: Remove bogus sync_char_short
effective target.
* gcc.dg/torture/bitint-87.c: Likewise.
* gcc.dg/torture/bitint-88.c: New test.
* gcc.dg/torture/bitint-89.c: New test.
Reviewed-by: Jeffrey Law <jeffrey.law@oss.qualcomm.com>
Soumya AR [Fri, 17 Apr 2026 03:02:11 +0000 (03:02 +0000)]
aarch64: Minor fixes for narrow-gp-writes pass
This patch addresses the following fixes:
- Remove the redundant checks for SUBREG and TRUNCATE.
- Bail out of recursive narrowing in narrow_dimode_src when an operand remains
DImode.
- Use HOST_WIDE_INT_PRINT_HEX instead of %lx for printing the mask.
Bootstrapped and regtested on aarch64-linux-gnu.
Signed-off-by: Soumya AR <soumyaa@nvidia.com>
gcc/ChangeLog:
* config/aarch64/aarch64-narrow-gp-writes.cc (narrow_dimode_src): Remove
redundant checks. Don't recurse when an operand remains DImode.
(narrow_gp_writes::optimize_compare_arith_insn): Use
HOST_WIDE_INT_PRINT_HEX.
(narrow_gp_writes::optimize_single_set_insn): Likewise.
The PR is about an ICE on sh caused by an "invalid" subreg.
cse replaced a pseudo register with the hard T register within:
(zero_extend:SI (subreg:QI (reg:SI pseudo) 3))
Since this is a register-for-register replacement, cse just relied on
recog to reject anything that wasn't valid.
However, if validate_subreg had been asked, it would have said that:
(subreg:QI (reg:SI T) 3)
is not valid. This means that even simplify_gen_subreg would have
refused to generate it.
In that sense, cse should not even be trying to match this replacement.
It's not recog's job to reject all invalid rtl. recog is just supposed
to say whether the machine supports a given piece of valid rtl.
In this particular case, the sh port does specifically match:
(zero_extend:SI (subreg:QI (reg:SI T) 3))
even though, by forbidding T from having QImode, the port also
effectively forbids the subreg. See the discussion in the PR trail
about that. But I think the point still stands that cse should verify
the subregs that it creates. It should also try to simplify them down
to hard registers where possible.
I suppose a more complete fix would be to rewrite canon_reg to use a
helper that recursively replaces and simplifies, but that seems somewhat
dangerous at this stage. The scope for non-subreg simplification should
also be pretty limited in practice.
gcc/
PR rtl-optimization/124643
* cse.cc (canon_reg): Handle and canonicalize subregs.
gcc/testsuite/
PR rtl-optimization/124643
* gcc.c-torture/compile/pr124643.c: New test.
Patrick Palka [Sat, 18 Apr 2026 23:25:59 +0000 (19:25 -0400)]
libstdc++: Fix constantness of engaged -> disengaged std::optional [PR124910]
When an optional that contains a value is cleared, _M_destroy invokes the
destructor of the contained value _Storage::_M_value, leaving the union
_Storage without an active member. While this is benign at runtime, a
union suboject with no active member violates core constant expression
requirements and in turn an optional in this state can't be used as a
constant initializer, which Clang and recent GCC (since r16-3022) correctly
diagnose.
To fix this, this patch makes _M_destroy activate the dummy union member
_M_empty after destroying _M_value to ensure that the union always has
an active member throughout its lifetime. We use std::construct_at
instead of simple assignment to work around a front end bug (comment #3
in the PR). Doing so means we don't activate the member in C++17 mode,
which should be fine; I don't think it's possible to disengage an engaged
optional using only the C++17 constexpr optional operations.
PR c++/124910
libstdc++-v3/ChangeLog:
* include/std/optional (_Optional_payload_base::_M_destroy)
[__cpp_lib_optional >= 202106L]: During constant evaluation,
after invoking destructor of _M_value, use construct_at to
activate _M_empty.
* testsuite/20_util/optional/constexpr/124910.cc: New test.
d: Fix ICE in gimplify_var_or_parm_decl, at gimplify.cc:3308
The result type of the assert() should always be the same as its
inferred expression type, which could either be `void' or `noreturn'.
Also moves the pattern of calling to BUILT_IN_TRAP to its own codegen
function, as it is repeated quite enough throughout the front-end.
PR d/124922
gcc/d/ChangeLog:
* d-codegen.cc (build_trap_call): New function.
(build_array_bounds_call): Use it.
(build_bounds_index_condition): Likewise.
(build_bounds_slice_condition): Likewise.
(d_build_call): Likewise.
* expr.cc (ExprVisitor::visit (HaltExp *)): Likewise.
(ExprVisitor::visit (AssertExp *)): Likewise. Return zero instead of
void_node when assert contracts are disabled.
* d-tree.h (build_trap_call): New prototype.
The bswaphi pattern generates 2 assembly instructions with a length
of 8 bytes. The bswaphi pattern missed the length attribute, as a
result the default of 8 bytes was assumed. This allowed the "8 byte"
bswaphi pattern to be scheduled into the delay slot of a branch
instruction where only a 4 byte instruction can be placed. This
patch addresses the problem.
Eric Botcazou [Fri, 17 Apr 2026 20:26:56 +0000 (22:26 +0200)]
Ada: Fix excessive compilation time for decimal literal with large exponent
This is a serious contender for the smallest chunk of code still hanging the
compiler after three decades.
gcc/ada/
PR ada/107392
* sem_res.adb: Add clauses for Ttypes.
(Resolve.Patch_Up_Value): Do not try to convert real literals that
do not fit in Universal_Integer.
gcc/testsuite/
* gnat.dg/specs/float_literal2.ads: New test.
Eric Botcazou [Fri, 17 Apr 2026 20:22:07 +0000 (22:22 +0200)]
Ada: Fix internal error on decimal literal with huge exponent
This is a serious contender for the smallest chunk of code still crashing
the compiler after three decades.
gcc/ada/
PR ada/107391
* urealp.adb (Decimal_Exponent_Hi): Check that the denominator is
in range before invoking UI_To_Int on it, and cope with failure.
(Decimal_Exponent_Lo): Likewise.
gcc/testsuite/
* gnat.dg/specs/float_literal1.ads: New test.
Patrick Palka [Fri, 17 Apr 2026 15:19:58 +0000 (11:19 -0400)]
libstdc++: Fix constraint recursion in std::indirect's operator== [PR124890]
Like in r16-559 for std::expected, std::indirect's operator== is also
prone to constraint recursion due to CWG 2369, for the Mandates that we
implement as an associated constraint. This patch works around the
recursion in a similar manner as done for std::expected (and
std::basic_const_iterator).
* include/bits/indirect.h (indirect::operator==): Replace
non-dependent std::indirect function parameter with a
dependent one of type indirect<_Vp> where _Vp matches _Tp.
* testsuite/std/memory/indirect/124890.cc: New test.
Jan Hubicka [Fri, 17 Apr 2026 16:10:09 +0000 (18:10 +0200)]
Fix lto-devirt-23.C testcase failure
The testcase now fails because we miss the fact that type can be in construction.
This is because polymorphic_ctor_dtor_p returns false on polymorphic destructor
since it has PURE flag. The problem is that the destructor is optimized in meantime
and the memory store is optimized out. It is however left intact in the inline copy
of the constructor, so we can't really use the flag.
This check was added during early stage of the development of ipa-devirt and it
is not very effective (does not trigger anything useful on testsuite or GCC bootstrap).
So this patch simply drops it.
gcc/ChangeLog:
PR ipa/120098
* ipa-polymorphic-call.cc (polymorphic_ctor_dtor_p): Remove
check for pure/const flags
Jan Hubicka [Fri, 17 Apr 2026 15:34:35 +0000 (17:34 +0200)]
Fix handling of anonymous type vtables in ipa-devirt
Solve first problem discussed in PR120098 where modified
devirt-23 testcase leads to wrong code. The testcase triggers situation
whre anonymous type MultiTermDocs is derived by C. When we look for possible
polymorphic call targets, we special case anonymous type and check if they
have been instantiated by looking if their virtual table is used at all.
In this case it is not, however C has construction vtable which refers to
MultiTermDocs's virtual function.
Since we have no easy way to go from a type to all construction vtables
of its derived types, this is fixed by adding a walk of variables
and noting them. Walk is triggered lazilly only when such anonymous types
exists.
gcc/ChangeLog:
PR ipa/120098
* ipa-devirt.cc (odr_type_p): Add no_derived_construction_vtables
(odr_types_ptr): Move ahead in file.
(odr_types): Move ahead in file.
(anonymous_construction_vtable_p): New function.
(mark_derived_construction_vtables): New function.
(construction_vtable_hook): New function.
(type_possibly_instantiated_p): Watch for construction vtables.
gcc/testsuite/ChangeLog:
PR ipa/120098
* g++.dg/torture/pr120098.C: New test.
...to use the narrower DECL_FUNCTION_TEMPLATE_P instead of
really_overloaded_fn. Also make the parameter const_tree.
gcc/cp/ChangeLog:
* cp-tree.h (reflection_function_template_p): Change the
parameter to const_tree.
* reflect.cc (valid_splice_for_member_access_p): Use
reflection_function_template_p.
(reflection_function_template_p): Check DECL_FUNCTION_TEMPLATE_P
instead of really_overloaded_fn. Unwrap BASELINKs and OVERLOADs.
Adjust the parameter type.
We have 'gfortran.dg/goacc-gomp/goacc-gomp.exp'; use it for this OpenACC/OpenMP
test case added in commit 3d4039e95d851b8543884962ecf1a8e9e20669a8
"fortran: Fix free-form mixed OpenACC/OpenMP continuation state":
'gfortran.dg/goacc/omp-108382.f90' -> 'gfortran.dg/goacc-gomp/pr108382.f90'.
Thomas Schwinge [Wed, 15 Apr 2026 08:14:07 +0000 (10:14 +0200)]
openmp: Handle rest of EXEC_OACC_* in oacc_code_to_statement [PR93463]: 'gfortran.dg/goacc/pr93463.f90' -> 'gfortran.dg/goacc-gomp/pr93463.f90'
We (nowadays) have 'gfortran.dg/goacc-gomp/goacc-gomp.exp'; use it for this
OpenACC/OpenMP test case added in
commit aa1b56967d85bfc80d71341395f862ec2b30ca36
"openmp: Handle rest of EXEC_OACC_* in oacc_code_to_statement [PR93463]":
'gfortran.dg/goacc/pr93463.f90' -> 'gfortran.dg/goacc-gomp/pr93463.f90'.
Thomas Schwinge [Wed, 15 Apr 2026 08:16:11 +0000 (10:16 +0200)]
openmp: Teach omp_code_to_statement about rest of OpenMP statements: 'gfortran.dg/goacc/pr93329.f90' -> 'gfortran.dg/goacc-gomp/pr93329.f90'
We (nowadays) have 'gfortran.dg/goacc-gomp/goacc-gomp.exp'; use it for this
OpenACC/OpenMP test case added in
commit a38979d9d7a4ab08336436052704028c56187618
"openmp: Teach omp_code_to_statement about rest of OpenMP statements":
'gfortran.dg/goacc/pr93329.f90' -> 'gfortran.dg/goacc-gomp/pr93329.f90'.
Thomas Schwinge [Wed, 15 Apr 2026 08:28:03 +0000 (10:28 +0200)]
[PR fortran/63858] Fix mix of OpenACC and OpenMP sentinels in continuations: 'gfortran.dg/goacc/omp-fixed.f' -> 'gfortran.dg/goacc-gomp/pr63858.f'
We (nowadays) have 'gfortran.dg/goacc-gomp/goacc-gomp.exp'; use it for this
OpenACC/OpenMP test case added in r230872
(commit aa81272c9f98818910466728a58425d44884983a)
"[PR fortran/63858] Fix mix of OpenACC and OpenMP sentinels in continuations":
'gfortran.dg/goacc/omp-fixed.f' -> 'gfortran.dg/goacc-gomp/pr63858.f'.
Thomas Schwinge [Wed, 15 Apr 2026 08:26:09 +0000 (10:26 +0200)]
Merge current set of OpenACC changes from gomp-4_0-branch: 'gfortran.dg/goacc/omp.f95' -> 'gfortran.dg/goacc-gomp/nesting-fail-1.f95'
We (nowadays) have 'gfortran.dg/goacc-gomp/goacc-gomp.exp'; use it for this
OpenACC/OpenMP test case added in r219682
(commit 41dbbb3789850dfea98dd8984f69806284f87b6e)
"Merge current set of OpenACC changes from gomp-4_0-branch":
'gfortran.dg/goacc/omp.f95' -> 'gfortran.dg/goacc-gomp/nesting-fail-1.f95'.
gcc/testsuite/
* gfortran.dg/goacc/omp.f95: Move...
* gfortran.dg/goacc-gomp/nesting-fail-1.f95: ... here, and adjust.
Thomas Schwinge [Tue, 14 Apr 2026 15:29:59 +0000 (17:29 +0200)]
openmp: ensure variables in offload table are streamed out (PRs 94848 + 95551): OpenACC test case
The test case 'libgomp.fortran/target-var.f90' added in
commit 1c0fdaf79e3618fd7512608a2e5c62b6b306e9e8
"openmp: ensure variables in offload table are streamed out (PRs 94848 + 95551)"
alluded to an OpenACC variant in addition to OpenMP 'target', but didn't
actually add it -- do that now. Via reverting the applicable compiler-side
code changes, I've re-confirmed that the original problem also applied to
OpenACC.
For good measure, also fix up the OpenACC: the array assignment/constructor
before the loop and 'if'/'any' check after the loop execute in gang-redundant
mode, which -- in presence of multiple gangs executing, as implied by the
OpenACC 'loop' construct with 'gang' clause -- is dubious, even if probably
benign in this specific case here, I suppose. Use OpenACC 'kernels' instead.
PR middle-end/95551
libgomp/
* testsuite/libgomp.fortran/target-var.f90: Rename to...
* testsuite/libgomp.fortran/pr95551-1.f90: ... this, and fix up the
OpenACC.
* testsuite/libgomp.oacc-fortran/pr95551-1.f90: New.
Thomas Schwinge [Thu, 16 Apr 2026 22:53:24 +0000 (00:53 +0200)]
gccrs: Add `#![no_core]` attribute to most tests: ..., but not in '[...].exp' test suite harness files
Always good to be comprehensive when mass-editing files, but the '[...].exp'
test suite harness files are good already without 'no_core' annotation. ;-)
Thomas Schwinge [Thu, 16 Apr 2026 22:46:32 +0000 (00:46 +0200)]
gccrs: ast: Fix module path resolution for sibling modules in root: Simplify 'rust/compile/issue_4402_foo.rs' special-casing
In Rust-GCC/gccrs#4406 commit e429012267c30f23c416bfa2db41d92abe472d18
"gccrs: ast: Fix module path resolution for sibling modules in root", I spotted
'rust/compile/issue_4402_foo.rs' special-casing via 'rust/compile/compile.exp'.
We can instead simply using some standard DejaGnu idiom, like 'dg-skip-if' for
'*-*-*', which turns that one into the expected:
Thomas Schwinge [Fri, 17 Apr 2026 08:20:51 +0000 (10:20 +0200)]
vect: fix vectorization of non-gather elementwise loads: Unrestrict test cases [PR124037]
Contrary to an earlier revision of them, in my understanding, the test cases
'g++.dg/vect/vect-pr124037.cc', 'gcc.dg/vect/vect-pr124037.c' as added in
commit 4a30b45ffe3cb4ad2e35d73f1714f1a80e32edd7
"vect: fix vectorization of non-gather elementwise loads [PR124037]"
are no longer specific to early break vectorization, and the C++ one also
doesn't use 'mmap'.
Thomas Schwinge [Fri, 10 Apr 2026 14:51:48 +0000 (16:51 +0200)]
libgomp: fix omp_target_is_present and omp_get_mapped_ptr: Fix up 'libgomp.c/omp_target_is_present.c'
It's probably a general issue that we don't 'omp_target_disassociate_ptr' after
'omp_target_associate_ptr', but in a multi-device setting, this results in an
execution test FAIL.
Jakub Jelinek [Fri, 17 Apr 2026 13:05:14 +0000 (15:05 +0200)]
libstdc++: Further baseline_symbols.txt updates
Unlike the previous patch which was (except for powerpc64-linux) actually
done from looking at actual libstdc++.so.6.0.35 symbols on each arch,
the following is all guesses.
Given the change analysis done in previous patch, I've updated
baseline_symbols.txt which have been updated in GCC 15 by applying the
aarch64-linux-gnu baseline_symbols.txt patch for targets which use
m size_t mangling and i486-linux-gnu baseline_symbols.txt patch for
targets which use j size_t mangling.
Skipped targets which haven't been updated in GCC 15 and hppa-linux-gnu
where the patch didn't apply cleanly.
We don't want to export std::vprint_unicode etc. from libstdc++.so yet,
but we can give users the option of improving compile times by getting
the definitions of the std::print internals from libstdc++exp.a instead.
This commit adds a macro, _GLIBCXX_NO_INLINE_PRINT, which disables the
inline definitions of std::vprint_unicode etc. so that extern
definitions in libstdc++exp.a can be used instead.
With this change compiling a helloworld using std::print goes from 8s to
under 2s with trunk. For release branches with --enable-checking=release
we should see even faster times. The object file size is also
dramatically smaller, because there's just a single call to an extern
function instead of instantiating the entire std::print and std::format
implementation inline.
libstdc++-v3/ChangeLog:
PR libstdc++/124410
* doc/html/*: Regenerate.
* doc/xml/manual/using.xml (_GLIBCXX_NO_INLINE_PRINT): Document
macro.
* include/Makefile.am: Add bits/print.h and bits/ostream_print.h
headers.
* include/Makefile.in: Regenerate.
* include/std/ostream (vprint_nonunicode, vprint_unicode): Move
definitions to new bits/ostream_print.h header.
* include/std/print (__format::_File_sink, vprint_nonunicode)
(vprint_nonunicode_buffered, vprint_unicode)
(vprint_unicode_buffered): Move definitions to new bits/print.h
header.
* src/c++23/print.cc: Include new headers to define symbols for
inline print functions.
* include/bits/ostream_print.h: New file.
* include/bits/print.h: New file.
Jakub Jelinek [Fri, 17 Apr 2026 12:25:48 +0000 (14:25 +0200)]
libstdc++: Update baseline_symbols.txt on some Linux arches
The following patch updates baseline_symbols.txt files.
Most of these come from Fedora package builds, i386 used to be the same as
i486 in GCC <= 11 but hasn't been updated since, so the changes are larger
there. riscv64 is from my build on cfarm95 where i'm debugging bitint
issues currently. powerpc64 is hand edited mix of powerpc64le and old
powerpc64 (i.e. basically powerpc64le with IEEE stuff and DF128/DF64x stuff
removed).
Verification of the changes (ignoring the i386 changes which are across
multiple GCC versions) looks ok, in particular:
grep ^- patchwithouti386 | grep -v ^---
yields nothing
grep ^+ patchwithouti386 | grep -v ^+++ | grep -v GLIBCXX_3.4.35 | grep -v CXXABI_1.3.17
yields also nothing
grep ^+ patchwitouti386 | grep -v ^+++ | sort | uniq -c | sort -n
shows mostly 8 occurrences of stuff, the exceptions are just
1 +OBJECT:16:_ZTIDF16_@@CXXABI_1.3.17
1 +OBJECT:32:_ZTIPDF16_@@CXXABI_1.3.17
1 +OBJECT:32:_ZTIPKDF16_@@CXXABI_1.3.17
2 +FUNC:_ZNSt12__cow_stringC2EPKcj@@GLIBCXX_3.4.35
2 +FUNC:_ZNSt8__detail17__wait_until_implEPKvRNS_16__wait_args_baseERKNSt6chrono8durationIxSt5ratioILx1ELx1000000000EEEE@@GLIBCXX_3.4.35
6 +FUNC:_ZNSt12__cow_stringC2EPKcm@@GLIBCXX_3.4.35
6 +FUNC:_ZNSt8__detail17__wait_until_implEPKvRNS_16__wait_args_baseERKNSt6chrono8durationIlSt5ratioILl1ELl1000000000EEEE@@GLIBCXX_3.4.35
The 6 vs. 2 is unsigned int vs. unsigned long difference, supposedly
size_t, and _ZTI*DF16_ are new just on s390x intentionally.
Andre Vieira [Fri, 17 Apr 2026 10:13:07 +0000 (11:13 +0100)]
arm, bitint: Add support for FP_HANDLE_EXCEPTIONS and FP_ROUNDMODE with hard float abi
This patch adds support for FP_HANDLE_EXCEPTIONS when using hard float abi.
This is used by _BitInt software emulation for floating point conversions to
throw an exception.
This patch also adds support for FP_ROUNDMODE with hard float abi, which is
also used by _BitInt floating point emulation.
libgcc/ChangeLog:
* config/arm/sfp-exceptions.c: New file.
* config/arm/sfp-machine.h: Define FP_HANDLE_EXCEPTIONS, FP_EX_*
MACROs, _FP_DECL_EX, FP_ROUNDMODE, FP_INIT_ROUNDMODE, FP_RND_* MACROs
and declare __sfp_handle_exceptions.
* config/arm/t-softfp: Add sfp-exceptions.c to LIB2ADD.
Jonathan Wakely [Wed, 11 Mar 2026 21:05:13 +0000 (21:05 +0000)]
libstdc++: Add module initialization functions to the library [PR124268]
This tries to ensure that the module init functions are present in
libstdc++.so and libstdc++.a, so that users of the std and std.compat
modules don't need to manually link to std.o and/or std.compat.o in
addition to compiling the CMIs.
This also adds a clean-local target to remove the generated interface
units and manifest, and the gcm.cache directory for the CMIs.
This was previously committed and then reverted because it broke
bootstrap on a few targets. Most of the reasons the module interface
units failed to compile have (we believe) now been addressed with G++
changes, although there's still a problem on amdgcn (PR124554). Due to
that problem, and any not yet known problems, this version of the patch
tries to avoid breaking bootstrap again by allowing the modules to fail
to compile. If compiling std.o or std.compat.o fails then an empty
translation unit will be compiled and added to libstdc++.so instead.
This means that we will only export the module initialization functions
from the library if the module can be compiled for the target. This
seems fine because we don't need to initialize anything for a module
that cannot even be compiled! Fixing PR124554 and removing this kluge
should be done for GCC 17 in stage 1.
libstdc++-v3/ChangeLog:
PR libstdc++/124268
* config/abi/pre/gnu.ver: Export symbols.
* src/Makefile.am: Add libmodulesconvenience.la to libstdc++
link.
* src/Makefile.in: Regenerate.
* src/c++23/Makefile.am: Create libmodulesconvenience.la
and populate it with std.o and std.compat.o interface units,
with empty fallback objects if compiling the interface units
fails. Add clean-local target.
* src/c++23/Makefile.in: Regenerate.
Tamar Christina [Fri, 17 Apr 2026 06:46:07 +0000 (07:46 +0100)]
middle-end: disable CRC pass when -Os and the target does not have CRC optabs [PR124900]
The example
#include <stdint.h>
#include <stddef.h>
uint32_t crc32(const uint8_t *data, size_t length)
{
uint8_t i;
uint32_t crc = 0xffffffff; // Initial value
while (length--) {
crc ^= (uint32_t)(*data++) << 24;
#pragma GCC unroll 0
for (i = 0; i < 8; ++i) {
if (crc & 0x80000000)
crc = (crc << 1) ^ 0x04C11DB7;
else
crc <<= 1;
}
}
return crc;
}
when compiled with -Os -march=armv8-a increases the codesize significantly
because it generates a loop that's as big as the original but adds a lookup
table of 255 * 4 bytes. This means it's actively making codesize bigger and
introduces a codesize regression from before the pass was added.
This patch disables the CRC table based expansion when compiling for size.
gcc/ChangeLog:
PR middle-end/124900
* gimple-crc-optimization.cc (crc_optimization::optimize_crc_loop): Do
not expand to table when compiling for size.
(class crc_optimization): Update prototype of optimize_crc_loop to
include loop.
(crc_optimization::execute): Pass loop to optimize_crc_loop.
gcc/testsuite/ChangeLog:
PR middle-end/124900
* gcc.target/aarch64/crc-1.c: New test.
* gcc.target/aarch64/crc-2.c: New test.
* gcc.target/aarch64/crc-3.c: New test.
* gcc.target/aarch64/crc-4.c: New test.
Jakub Jelinek [Fri, 17 Apr 2026 05:52:07 +0000 (07:52 +0200)]
c++: -Wkeyword-macro vs. contracts
contract_assert is a keyword listed in c_common_reswords for D_CXX26,
so no need to call cpp_warn separately on it, it is called already in
tree id = get_identifier (c_common_reswords[i].word);
if (IDENTIFIER_KEYWORD_P (id)
/* Don't register keywords with spaces. */
&& IDENTIFIER_POINTER (id)[IDENTIFIER_LENGTH (id) - 1] != ' ')
cpp_warn (parse_in, IDENTIFIER_POINTER (id),
IDENTIFIER_LENGTH (id));
earlier. contract_assert is also the only -fcontracts related keyword in
https://eel.is/c++draft/lex.key#tab:lex.key . On the other side, pre/post
are identifiers with special meaning: https://eel.is/c++draft/tab:lex.name.special
and so need to be handled. Note, contract_assert is also already correctly
tested in those tests.
2026-04-17 Jakub Jelinek <jakub@redhat.com>
* lex.cc (cxx_init): Don't call cpp_warn on contract_assert,
instead call it on pre and post.
* g++.dg/warn/Wkeyword-macro-1.C: Expect error for pre/post for C++26.
* g++.dg/warn/Wkeyword-macro-2.C: Expect warning for pre/post for
C++26.
* g++.dg/warn/Wkeyword-macro-4.C: Expect error for pre/post for C++26.
* g++.dg/warn/Wkeyword-macro-5.C: Expect warning for pre/post for
C++26.
* g++.dg/warn/Wkeyword-macro-7.C: Likewise.
* g++.dg/warn/Wkeyword-macro-8.C: Likewise.
Jakub Jelinek [Fri, 17 Apr 2026 05:50:35 +0000 (07:50 +0200)]
c++: Reject splicing of function parameters [PR123783]
When discussing the PR recently, I've realized that we don't reject
splicing of function parameters, even when
http://eel.is/c++draft/expr.prim.splice#2
doesn't list function parameters anywhere and so
http://eel.is/c++draft/expr.prim.splice#2.7 should apply.
Note, this is something that can't be tested in check_splice_expr,
because REFLECT_EXPR_KIND isn't propagated to it and whether some
reflection is a reflection of a function parameter or variable_of thereof
only differentiates in that kind, otherwise it is PARM_DECL in both
cases. So, the following patch diagnoses it in splice function.
And for the case where using [:variable_of(e):] could make it valid
a message suggesting that is emitted too.
In mangle3.C I had to drop one test, it is now rejected and the
test tests mangling, so better shouldn't have errors in it.
For the dep14.C case, I've applied variable_of on it so that we get
the previous behavior. And in func2 there it was actually (I think
mistakenly) asking for paramete of func rather than func2, fixed that too.
2026-04-17 Jakub Jelinek <jakub@redhat.com>
PR c++/123783
* reflect.cc (splice): Reject splicing of function parameters.
* g++.dg/reflect/mangle3.C: Remove f5<parameters_of (^^g)[0]>()
case.
* g++.dg/reflect/dep14.C: Include <ranges>.
(func): Apply variable_of to each vector member.
(func2): Likewise. Use ^^func2 instead of ^^func.
* g++.dg/reflect/splice12.C: New test.
Jason Merrill [Fri, 17 Apr 2026 02:41:24 +0000 (22:41 -0400)]
c++: constexpr call hashing and gc [PR124632]
In cxx_eval_call_expression, we unshare an argument that goes into
constexpr_call::bindings so it's independent, and then if it's a CONSTRUCTOR
we unshare it again before putting it in the constexpr value hashtable so
any modifications within the function don't affect the bindings. And then
we free these latter CONSTRUCTOR if they aren't part of the return value.
In explicit-obj-lambda2.C, cl5 is a recursive constexpr lambda that takes a
class (the closure) by value. If -Wtautological-compare is enabled, we try
to constant-fold cl5(5) to see if has a constant value. In evaluating the
outer call we have an empty CONSTRUCTOR argument {} that we unshare twice.
When we try to evaluate the recursive call, the second unshare from the
first call initially goes into bindings. But since this is a recursive call
get_fundef_copy needs need to make a copy of the FUNCTION_DECL, and since
this evaluation is for a warning uid_sensitive_constexpr_evaluation_p is
true, so we can't make a copy, so evaluating the recursive copy fails
without ever unsharing the argument.
Then when we get back to finishing up the outer call we ggc_free the
unshared CONSTRUCTOR that we don't need anymore. But the recursive call
already added it to the constexpr_call_table, so now the entry there is
referring to freed memory.
The solution is doing the first unshare immediately when we create the entry
in the constexpr_call_table, not later after get_fundef_copy. This should
also mean less unsharing, as we now only do the first unshare when creating
the constexpr_call_table entry, not on subsequent evaluations. This only
affects uncacheable calls, but that's a significant subset.
Jakub Jelinek [Thu, 16 Apr 2026 17:13:48 +0000 (19:13 +0200)]
c++: Temporarily ignore -Wformat* warnings in dump_data_member_spec
The body of this function has been moved from eval_display_string_of,
which ignored some warnings already.
The new function doesn't ignore those, we we get
../../gcc/cp/reflect.cc: In function ‘void dump_data_member_spec(pretty_printer*, tree)’:
../../gcc/cp/reflect.cc:3692:18: warning: ‘T’ conversion used unquoted [-Wformat=]
3692 | pp_printf (pp, "(%T, %E, %E, %E, %s, {", TREE_VEC_ELT (r, 0),
| ^~~~~~~~~~~~~~~~~~~~~~~~
../../gcc/cp/reflect.cc:3692:18: warning: spurious trailing punctuation sequence ‘{’ in format [-Wformat-diag]
../../gcc/cp/reflect.cc:3692:18: warning: unbalanced punctuation character ‘{’ in format [-Wformat-diag]
../../gcc/cp/reflect.cc:3699:18: warning: unbalanced punctuation character ‘}’ in format [-Wformat-diag]
3699 | pp_printf (pp, "})");
| ^~~~
../../gcc/cp/reflect.cc:3699:18: warning: unbalanced punctuation character ‘)’ in format [-Wformat-diag]
extra warnings which can break bootstrap when promoted into errors.
2026-04-16 Jakub Jelinek <jakub@redhat.com>
* reflect.cc (dump_data_member_spec): Temporarily ignore
-Wformat and -Wformat-diag warnings.
Richard Earnshaw [Thu, 16 Apr 2026 13:50:07 +0000 (14:50 +0100)]
arm: support +CDECP<n> options on cortex-m85
The Cortex-m85 CPU supports the CDE extension, which requires use of the
+cdecp<n> CPU name modifiers. This patch enables these options. This is
all pretty-much boiler-plate since Srinath added support on Cortex-m55.
gcc/ChangeLog:
* config/arm/arm-cpus.in (cortex-m85): Allow +cdecp<n>.
* doc/invoke.texi: Document this
gcc/testsuite/ChangeLog:
* gcc.target/arm/multilib.exp: Test CDE options on cortex-m85.
Marek Polacek [Wed, 15 Apr 2026 22:29:37 +0000 (18:29 -0400)]
c++/reflection: detect bad splices in class member access [PR124614]
This testcase shows that we still don't detect some invalid splices
used in a class member access. E.g. in,
b.[:reflect_constant (^^B::id):];
the splice designates a reflection which cannot be used in obj.[:R:].
We can enhance check_splice_expr to check for exactly those codes
that can be handled. This is also an opportunity to finally factor
our the long splice_p checks into a helper.
where we don't correctly print the RHS, thus the dump_data_member_spec
addition.
PR c++/124614
gcc/cp/ChangeLog:
* cp-tree.h (valid_splice_for_member_access_p): Declare.
(dump_data_member_spec): Declare.
* error.cc (dump_expr) <case REFLECT_EXPR>: Print a data member
description.
* parser.cc (cp_parser_splice_expression): Use
valid_splice_for_member_access_p.
* pt.cc (tsubst_splice_expr): Likewise.
* reflect.cc (dump_data_member_spec): New.
(eval_display_string_of): Use it.
(valid_splice_for_member_access_p): New.
(check_splice_expr): Check that we got
valid_splice_for_member_access_p for a member access.
* typeck.cc (finish_class_member_access_expr): Use
valid_splice_for_member_access_p.
Jakub Jelinek [Thu, 16 Apr 2026 13:51:04 +0000 (15:51 +0200)]
c++: Fix up expansion-stmt mangling ICE [PR124120]
One of the reflect/* tests ICEs on Solaris but not on Linux (at least not
when using recent glibc).
I've tracked it down to a problem with expansion statements, due to the
workaround we have for missing part of P2686R4 where we make some artificial
vars static. Some of them (the __for_range and __for_begin) have DECL_NAMEs
(with a space in it) and so even when they are static, don't cause problems.
But the iter variable (in https://eel.is/c++draft/stmt.expand#5.2 ) is when
constexpr still static and was nameless.
Now, because it is constexpr and not odr used, it is optimized out, but if
the TU also contains weakref attribute or something else that requires
cgraph to construct assembler_name_hash, we ICE when trying to mangle
the iter nameless variable.
The following patch fixes that by giving it yet another artificial name.
2026-04-16 Jakub Jelinek <jakub@redhat.com>
PR c++/124120
* pt.cc (finish_expansion_stmt): Give iter variable an artificial
name.
Jakub Jelinek [Thu, 16 Apr 2026 13:19:23 +0000 (15:19 +0200)]
stormy16, xtensa: Set TREE_PUBLIC on TYPE_NAME of __va_list_tag [PR124565]
Apparently stormy16 and xtensa suffer from the same problem as alpha and
sh, in particular that
module;
#include <cstdarg>
export module pr124565;
export namespace std {
using std::va_list;
}
fails to compile with -fmodules.
Fix is the same as for alpha/sh.
2026-04-16 Jakub Jelinek <jakub@redhat.com>
PR target/124565
* config/stormy16/stormy16.cc (xstormy16_build_builtin_va_list): Set
TREE_PUBLIC on type_decl.
* config/xtensa/xtensa.cc (xtensa_build_builtin_va_list): Likewise.
Paul Thomas [Thu, 16 Apr 2026 13:09:49 +0000 (14:09 +0100)]
Fortran: Fix dependencies in elemental subroutine calls [PR120140]
2026-04-16 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/120140
* resolve.cc (resolve_elemental_dependencies): New function,
preceded by prototype for add_temp_assign_before_call.
(resolve_call): If an elemental subroutine call has at least
two actual erguments, call resolve_elemental_dependencies to
generate temporary expressions for the arguments if required.
(get_temp_from_expr): Add optional boolean argument, which if
set, makes the resulting temporary unconditionally allocatable.
(add_temp_assign_before_call): New function.
gcn: doc/install.texi - fix by-default required LLVM version [PR124897]
The default multilib requires the linker + assembler of LLVM 20 not 19.
While LLVM 19 supports gfx942 and generic archs, it does not yet support
gfx9-4-generic.
gcc/ChangeLog:
PR target/124897
* doc/install.texi (amdgcn-amdhsa): Fix required LLVM version for
default multilib.
Tomasz Kamiński [Fri, 3 Apr 2026 11:39:20 +0000 (13:39 +0200)]
libstdc++: Export explicit instantiations of __format::__do_vformat_to.
This patch extracts a __format::__do_vformat_to for the _Sink_iter
(and matching format context) and exports explicit instantiations
of it for char and wchar_t. As every format function is implementing
as delegating to one of these overloads, this significantly reduces
the compilation time.
Instantiating __format::__do_vformat_to triggers specializations of
formatters for types stored in basic_format_arg directly (arithmetic
types, strings). In case when their behavior depends on the TU specific
configuration, only one configuration can be exported from shared
lib. In case of beforementioned formatters:
* ? (debug mode) is accepted in for strings and characters
* multibyte utf-8 encoded character is accepted as fill when the
literal encoding is Unicode.
The first issue is addressed by this patch, by declaring extern
definition only for the C++20. We will need to reconsider how to
handle the specifiers when C++23 becomes stable.
The literal encoding is handled by adding a second template parameter
to __do_vformat_to overload, that is initialized with 1 if literal
encoding is Unicode (the parameter has unsigned type to allow more
information to be encoded). This allows library to export implementation
for Unicode literal encoding (format-inst.cc is compiled with appropriate
flag), by declaring extern specialization only for value 1.
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu.ver (GLIBCXX_3.4): Exclude exports
of std::basic_fo* (matching basic_format_context).
(GLIBCXX_3.4.35): Export __format::__do_vformat_to
specializations for _Sink_iter and char/wchar_t.
* include/std/format: (__format::__do_vformat_to):
Extract overload accepting _Sink_iter and provide extern
explicit specialization for char/wchar_t in C++20 mode.
* src/c++20/Makefile.am: Add format-inst.cc.
* src/c++20/Makefile.in: Regenerate.
* src/c++20/format-inst.cc: New file defining explicit
instantiation.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
i386/testsuite: Fix pr90178.c test failure for 32-bit targets
The testcase counts occurrences of `xorl %eax, %eax` to detect whether
there is only one terminal basic block. This approach is brittle because
it depends on register allocation decisions, which differ between targets.
After the bbro pass, zero is not propagated from %ecx to %eax, so the final
assembly does not contain `xorl %eax, %eax`:
.L5:
xorl %ecx, %ecx
...
movl %ecx, %eax
ret
The test uses `xorl %eax, %eax` as a proxy for detecting multiple terminal
basic blocks, which is brittle because it depends on register allocation.
Instead, simply count `ret` instructions, which directly reflects the
number of terminal basic blocks and does not depend on register allocation.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr90178.c: Scan for 2 `ret` instructions.
Richard Biener [Tue, 14 Apr 2026 11:16:01 +0000 (13:16 +0200)]
middle-end/124877 - fix mis-apply of PROMOTE_PROTOTYPES
The following corrects how we apply PROMOTE_PROTOTYPES during RTL
expansion. The unsignedp field in args info is supposed to
denote the signedness of the unpromoted value, but we've set it
to the signedness of integer_type_node. So delay adjusting the
type until after we compute signedness of the formal argument.
This was originally changed for GCC16 with r16-169-g78db4753c9646a
and r16-170-ga670ebde399548.
The patch makes PROMOTE_PROTOTYPES newly affect transparent union
passing, promoting a smaller than int first element, which we
did not in GCC 15. gcc.target/i386/pr124877-2.c has a testcase
showing the effect nicely.
Overall this restores behavior to that of GCC 15 before we
moved PROMOTE_PROTOTYPES application from frontends to RTL
expansion, but GCC 15 did not apply promotion to the transparent
union case.
PR middle-end/124877
* calls.cc (initialize_argument_information): Compute
signedness of the formal argument type before applying
PROMOTE_PROTOTYPES promotion. Also apply promotion to
a smaller than int integer first member type of a
transparent union.
* target.def (promote_prototypes): Update documentation.
* doc/tm.texi: Re-generate.
* gcc.target/i386/pr124877-1.c: New testcase.
* gcc.target/i386/pr124877-2.c: Likewise.
* gcc.target/i386/pr124877-3.c: Likewise.
Jakub Jelinek [Thu, 16 Apr 2026 08:03:21 +0000 (10:03 +0200)]
i386: Fix up TARGET_AVOID_FALSE_DEP_FOR_BMI APX NF splitters [PR124892]
The following testcase is miscompiled because the 3
TARGET_AVOID_FALSE_DEP_FOR_BMI APX NF splitters use ix86_expand_clear.
All other uses of ix86_expand_clear are on either splitters where we know
something clobbers flags register or sets it at the end of pattern (so
clearly flags register is not live across the pattern) or in
define_peephole2 where we explicitly check peep2_regno_dead_p (?, FLAGS_REG).
Now, ix86_expand_clear handles right the QI/HImode cases by setting SImode
instead and based on TARGET_USE_MOV0 and/or optimize_insn_for_size_p
decides whether to use xor reg, reg form or mov $0, reg.
Now, for these 3 APX NF splitters there is actually no flags clobber nor set
in the pattern and because it is a splitter, we don't know if flags register
is live across it (likely yes, otherwise why the APX NF pattern would be
used) or not. So, we can't use ix86_expand_clear which could clobber flags.
As the splitters are only SWI48, we don't have to worry about QI/HImode
clearing and so IMHO just want to always use the mov $0, reg form by hand.
If flags actually isn't live across it, we have
;; Attempt to always use XOR for zeroing registers (including FP modes).
(define_peephole2
[(set (match_operand 0 "general_reg_operand")
(match_operand 1 "const0_operand"))]
"GET_MODE_SIZE (GET_MODE (operands[0])) <= UNITS_PER_WORD
&& (! TARGET_USE_MOV0 || optimize_insn_for_size_p ())
&& peep2_regno_dead_p (0, FLAGS_REG)"
[(parallel [(set (match_dup 0) (const_int 0))
(clobber (reg:CC FLAGS_REG))])]
"operands[0] = gen_lowpart (word_mode, operands[0]);")
peephole2 which would turn the mov $0, reg back to xor reg, reg.
2026-04-16 Jakub Jelinek <jakub@redhat.com>
PR target/124892
* config/i386/i386.md (clz<mode>2_lzcnt_nf,
<lt_zcnt>_<mode>_nf, popcount<mode>2_nf): Emit explicit
set of (match_dup 0) to (const_int 0) without flags clobber instead of
using ix86_expand_clear.
Jakub Jelinek [Thu, 16 Apr 2026 08:02:16 +0000 (10:02 +0200)]
tree-ssa-propagate: Call update_stmt before folding [PR124891]
The following testcase ICEs, because we
did_replace |= substitute_and_fold_engine->replace_uses_in (stmt);
and replace some SSA_NAME with INTEGER_CST and without update_stmt
call fold_stmt. Now fold_stmt ends up asking ranger about something end
ICEs because it attempts to walk SSA_USE_OPs on that stmt and because
we haven't updated the stmt, walks even the INTEGER_CST among ssa uses
and checking ICEs because it attempts to test SSA_NAME flags on the
INTEGER_CST.
The following patch fixes it by calling update_stmt before folding in that
case, it is called again after folding just in case it is folded.
2026-04-16 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/124891
* tree-ssa-propagate.cc
(substitute_and_fold_dom_walker::before_dom_children): Call update_stmt
in the did_replace case before calling fold_stmt.
testsuite: aarch64: ensure INT*_MIN macro definitions for C++ acle asm
VxWorks' libc doesn't define __STDC_LIMIT_MACROS when compiling C++98,
and then GCC's stdint.h doesn't define INT<N>_MIN, that a number of
acle asm testcases expect. If the macro is not defined, define the
macro in the header first included by all the affected tests, namely,
{div_s{32,64},mul_s{16,32,64,8}}.c.
Egas Ribeiro [Thu, 1 Jan 2026 03:41:14 +0000 (03:41 +0000)]
c++: fix constexpr union with empty member [PR123346]
r14-2820 changed cxx_eval_bare_aggregate to set no_slot based on whether
new_ctx.ctor is NULL_TREE, to handle empty subobject elision. However
this incorrectly omits entries for empty union members, which later need
the entry to exist.
This caused valid code to be rejected as non-constant after gcc 13.3,
and in trunk caused an ICE when the diagnostic code tries to print a
CONSTRUCTOR with a null value.
PR c++/123346
gcc/cp/ChangeLog:
* constexpr.cc (init_subob_ctx): Do initialize new_ctx.ctor
for an empty union member.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/constexpr-union10.C: New test.
Signed-off-by: Egas Ribeiro <egas.g.ribeiro@gmail.com> Co-authored-by: Jason Merrill <jason@redhat.com>
c++, contracts: implicit capture in lambda contract [PR124648]
We were currently accepting invalid code by allowing contract assertions
to trigger implicit lambda captures contrary to:
[expr.prim.lambda.closure] / p10.
The solution here is to mark captures that occur within contract
assertion scopes and then clear that mark if we then see a normal
capture for the same entity - we must defer the error handling since
the following is valid:
auto f5 = [=] {
contract_assert (i > 0); // OK, i is referenced elsewhere.
return i;
};
PR c++/124648
gcc/cp/ChangeLog:
* cp-tree.h (DECL_CONTRACT_CAPTURE_P): New.
* parser.cc (cp_parser_lambda_body): Scan the captures for
ones were only added in contract assertion scopes. Issue
errors for those found.
* semantics.cc (process_outer_var_ref): Mark implicit
captures that occur in contract assertion scopes. Clear
the mark if the entity is subsequently captured 'normally'.
(set_contract_capture_flag): New.
gcc/testsuite/ChangeLog:
* g++.dg/contracts/cpp26/expr.prim.lambda.closure.p10.C: New test.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> Co-authored-by: Jason Merrill <jason@redhat.com>
We need to view class pointers as const, which we do by wrapping
them in a view convert expression. However, we do not need to do
this if the original is already const-qualified.
gcc/cp/ChangeLog:
* contracts.cc (view_as_const): Check for const-qualified
class pointer before wrapping it.
* parser.cc (cp_parser_late_contract_condition): Use revised
handling of const-ification of class pointers.
(cp_parser_contract_assert): Likewise.
(cp_parser_function_contract_specifier): Likewise.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> Co-authored-by: Jason Merrill <jason@redhat.com>
Marek Polacek [Wed, 15 Apr 2026 18:15:06 +0000 (14:15 -0400)]
c++: ICE with deleted main [PR120338]
Here we ICE with deleted main which is later redefined at
gcc_assert (DECL_SAVED_TREE (fn));
because for some reason when deleting main I chose NULL_TREE instead of
error_mark_node as its DECL_INITIAL. For other deleted functions we
also use error_mark_node so that
void foo() = delete;
void foo() {}
results in the "redefinition of" error. Let's do the same for main, then.
PR c++/120338
gcc/cp/ChangeLog:
* decl.cc (cp_finish_decl): Set DECL_INITIAL to error_mark_node
instead of NULL_TREE for deleted main.
Gaius Mulley [Wed, 15 Apr 2026 17:34:23 +0000 (18:34 +0100)]
PR modula2/124081 Bugfix ICE in expand_expr_real_2 with a record
This patch fixes an ICE which occurs when attempting to create a
set using a subrange from a record field. The fix ensures that the
record field is copied to a temporary prior to the set construction.
PR modula2/124081
* gm2/iso/run/pass/setcons.mod: New test.
* gm2/iso/run/pass/setcons2.mod: New test.
* gm2/iso/run/pass/setcons3.mod: New test.
* gm2/iso/run/pass/setcons4.mod: New test.
* gm2/iso/run/pass/setcons5.mod: New test.
Marek Polacek [Wed, 15 Apr 2026 14:52:29 +0000 (10:52 -0400)]
c++/reflection: generic lambda with dependent splice [PR123783]
For a generic lambda, we normally collect the captures while parsing
the lambda: finish_id_expression calls process_outer_var_ref which does
add_capture. Then when instantiating, we'll find the capture via
retrieve_local_specialization. Once the closure type has been
finalized, it's frozen and we can't add new fields. This is what
happens in the following test though, which is the reason we crash:
[&]<auto> {
[:e:];
}
where while parsing we can't know what the splice will designate.
We'll only find out after we've substituted the splice but then it's
too late to capture anything.
A possible solution would be to speculatively capture all locals when
we see a dependent splice in a generic lambda. But since this test is
invalid anyway, that would be a lot of work for no good reason. So this
patch changes the internal_error to an ordinary error.
PR c++/123783
gcc/cp/ChangeLog:
* lambda.cc (add_capture): When trying to capture something in
an instantiation of generic lambda, give an error instead of an ICE.
gcc/testsuite/ChangeLog:
* g++.dg/reflect/dep14.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com> Reviewed-by: Patrick Palka <ppalka@redhat.com>
The philox counter increment that happens in
philox_engine::_M_transition(), applies +1 to _M_x[0] before the bitwise
OR with (_M_x[1] << __w), so the carry from _M_x[0] is merged into the
_M_x[1] portion rather than being added to it. This causes the counter
to cycle prematurely and never advance past {0, 0, 1, 2^w - 1}.
Fix by changing operations order, which results in forming the
full-width value from _M_x[1]:_M_x[0] and then adding 1 on both the n ==
4 and n == 2 paths.
libstdc++-v3/ChangeLog:
* include/bits/random.tcc (philox_engine::_M_transtiion): Fix
counter increment to propagate carry correctly.
* testsuite/26_numerics/random/philox_engine/operators/counter_carry.cc:
New test.
Signed-off-by: Elena Tyuleneva <elena.tyuleneva@intel.com> Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Patrick Palka <ppalka@redhat.com>
Jonathan Wakely [Wed, 15 Apr 2026 16:37:29 +0000 (17:37 +0100)]
libstdc++: Fix philox2x64 case for 32-bit targets
While testing a patch for std::philox_engine I noticed that
instantiating std::philox_engine with n=2 and w=64 fails on targets
without __int128, because it relies on an implicit conversion from the
intermediate counter type to the result type. When w=64 and the target
doesn't support __int128, we use the __rand_uint128 class type for the
intermediate counter values, but that does not support implicit
conversion to integral types.
This adds the necessary casts to make the conversions explicit.
libstdc++-v3/ChangeLog:
* include/bits/random.tcc (philox_engine::_M_transition): Cast
intermediate values to result_type for n=2 case.
Martin Jambor [Wed, 15 Apr 2026 16:28:32 +0000 (18:28 +0200)]
sra: Dont use build_reconstructed_reference on MEM_REFs changin types (PR122976)
PR122976 is basically a variant of PR105860 but instead of a union
there is a MEM_REF with a different type from the underlying DECL it
accesses. Like in the other bug, this confuses
build_reconstructed_reference which then finds wrong compatible base
and proceeds to identify a bogus FIELD_DECL to assign to a new access,
leading to memory accesses to a wrong place. This is caught by the
internal verifier when checking but unfortunately leads to
miscompilation without it. The patch fixes this by clearing
grp_same_access_path of such accesses so that
build_reconstructed_reference is not used at all for them.
The original testcase no longer exhibits the bug on master since r16-3201-gee67004474d521 (Andrew Pinski: forwprop: Copy prop
aggregates into args) but it turns out that my artificial one still
triggers.
If you want more details on what is going on, here they are, the issue
involves two VAR_DECLs:
which triggers code that tries to create accesses for LHS
corresponding to those collected for nextRef_1. Unfortunately the one
for offset 64 was created from access:
struct tyTuple__hnCuDR9cLe2lA3YIkwKIyuA {
NI Field0;
tySequence__6H5Oh5UUvVCLiakt9aTwtUQ Field1;
};
which is setting the len field after the type-cast but in terms of the
underlying type of the DECL, it is actually setting the pointer field.
Because SRA looks at the accesses rather than the types, it also means
that the access for the pointer was represented by a signed 64bit
integer and the stored expression was the above, two COMPONENT_REFs
bolted on top of the type changing MEM_REF. The access also got the
grp_same_access_path flag set, meaning we'd try to preserve the
"access path," the chain of handled_references in many contexts such
as propagating the accesses across assignments.
And there things went wrong, build_reconstructed_reference found the
MEM_REF, realized it was compatible with the base DECL and happily
assumed that means that whatever was used on top of the MEM_REF can be
used on top of the DECL to access the corresponding bit of memory.
The wrong bit was not clearing grp_same_access_path, which we for
example cleared when the MEM_REF had a non-zero offset and so this
patch detects the situation and clears it.
gcc/ChangeLog:
2026-03-15 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/122976
* tree-sra.cc (path_comparable_for_same_access): Return false if the
base is a MEM_REF with a different underlying type.
gcc/testsuite/ChangeLog:
2026-03-18 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/122976
* gcc.dg/tree-ssa/pr122976.c: New test.
Patrick Palka [Tue, 14 Apr 2026 19:36:54 +0000 (15:36 -0400)]
c++: reference to static local meta::info as targ [PR124824]
Here we're crashing in discriminator_for_local_entity during mangling
of f<&M>() because determine_local_discriminator is never called for
the static local meta::info M. The relevant code path in cp_finish_decl
was disabled for consteval-only types in the main Reflection commit
r16-6808 to avoid creating a varpool_node for such types.
This patch naively fixes this by moving the consteval_only_p check so
that we still call determine_local_discriminator for such types.
PR c++/124824
gcc/cp/ChangeLog:
* decl.cc (cp_finish_decl): Sink !consteval_only_p check to
only guard the varpool_node::get_create call.
Jakub Jelinek [Wed, 15 Apr 2026 15:28:53 +0000 (17:28 +0200)]
c++: Fix up constexpr EH handling of TARGET_EXPR temporaries [PR124755]
The following testcase is incorrectly rejected with spurious error about
<anonymous> used outside of its lifetime.
We constant evaluate
<<cleanup_point <<< Unknown tree: expr_stmt
(void) (n = TARGET_EXPR <D.2693, foo (m)>, n + D.2693) >>>>>;
in a loop, D.2693 is integral TARGET_EXPR_SLOT and foo throws in the second
or later iteration. Because D.2693 is not is_complex nor has
aggregate/vector type, we don't ctx->global->put_value (slot, something)
until the TARGET_EXPR_INITIAL evaluation successfully finishes, at which
point we ctx->save_exprs->safe_push (slot); and
ctx->global->put_value (slot, r); Because of the save_exprs push, the
CLEANUP_POINT_EXPR handling then
/* Forget SAVE_EXPRs and TARGET_EXPRs created by this
full-expression. */
for (tree save_expr : save_exprs)
destroy_value_checked (ctx, save_expr, non_constant_p);
and that ctx->global->put_value (slot, void_node); (i.e. marks it out of
lifetime). In the second iteration, we again don't call put_value on the
slot early, notice TARGET_EXPR_INITIAL evaluation throws, still
ctx->save_exprs->safe_push (slot); but then return. That means
the remembered value is still void_node and so destroy_value_checked
complains.
The following patch fixes that by calling put_value in the case where
we know we haven't changed it yet (i.e. it is not is_complex and it doesn't
have aggregate/vector type), so that destroy_value_checked doesn't complain.
2026-04-15 Jakub Jelinek <jakub@redhat.com>
PR c++/124755
* constexpr.cc (cxx_eval_constant_expression): If TARGET_EXPR_INITIAL
throws and !is_complex and type is neither aggregate nor vector,
call ctx->global->put_value (slot, NULL) before returning.
Jakub Jelinek [Wed, 15 Apr 2026 15:21:06 +0000 (17:21 +0200)]
bitintlower: Padding bit fixes, part 1 [PR123635]
x86_64/ia32/aarch64 say padding bits of _BitInt values have unspecified
values, and until GCC 16 those were the only supported _BitInt targets.
In GCC 16, we've added _BitInt support for some further arches,
loongarch, riscv, s390x and arm and all of them chose to specify the
padding bits (require zero or sign extension depending on whether the
type is signed or unsigned).
s390x is big-endian, on the other side has abi_limb_mode the same as
limb_mode, so the extension is always just within the same limb.
loongarch chose to require weird extension, only within the same limb
but not abi limb, so the current extensions are also mostly ok.
riscv and arm both use abi_limb_mode larger than limb_)mode and require
extension, which means that say for _BitInt(513) one needs to sign extend
not just within the limb corresponding to bit 512 (32-bit on arm, 64-bit
on loongarch), but within the whole abi limb (64-bit on arm, 128-bit on
loongarch), which means when working with the usual limbs we need to
extend another whole 32-bit or 64-bit limb above the one we'd normally
extend.
The following patch tweaks the bitint_info, so that it differentiates
between the different extension possibilities (x86_64/ia32/aarch64
bitint_ext_undef, loongarch bitint_ext_partial, arm/riscv bitint_ext_full,
s390x doesn't really matter if bitint_ext_partial or bitint_ext_full, but
chose to document bitint_ext_full and in gimple-lower-bitint.cc treat it
as bitint_ext_partial).
And then for a subset of lowerings handle it even for the
bitint_extended == bitint_ext_full cases.
In particular, this patch handles the mergeable stmts (like +/- and many
others which walk from least significant limb to most significant limb
and can handle 2 limbs in a loop), including the separate_ext extension
(where a mergeable operation is then extended to much wider _BitInt,
handled by handling normally the mergeable operation, remembering if
we should zero or sign extend (and whether to 0 or -1) and then in a
separate loop or straight line code store the 0s or -1s), division/modulo
(these are done by forcing larger prec on the output, modulo result
should never be larger than the first operand and same sign, division
of negative minimum by -1 is UB and otherwise also should be never larger
than first operand), signed multiplication (again, done by extending
prec because signed multiplication overflow is UB), unsigned multiplication
(this one can't be handled that way because unsigned mult overflow wraps,
so we need to pass exact lhs prec, so the code stores zero limb when
needed), and conversions from floating point (binary or decimal) to _BitInt
(signed or unsigned), those again are supposed to store minimum or maximum
value on overflow and so lhs prec needs to be maintained, so the code
for unsigned result clears one limb when needed or for signed result
right shifts the second most significant limb by limb prec - 1 and stores
that into most significant limb.
Note, <<, >>, add/sub overflow and mul overflow at least aren't done in
this patch, to be resolved incrementally.
2026-04-15 Jakub Jelinek <jakub@redhat.com>
PR middle-end/123635
* target.h (enum bitint_ext): New.
(struct bitint_info): Change extend type from bool to enum bitint_ext
and document it.
* gimple-lower-bitint.cc (bitint_extended): Change type from bool
to enum bitint_ext.
(bitint_precision_kind): Change bitint_extended to bitint_ext_partial
from bitint_ext_full if limb_mode is the same as abi_limb_mode.
(bitint_large_huge::limb_access_type): For
bitint_extended == bitint_ext_full allow access to the most
significant limb solely with padding bits if present.
(bitint_large_huge::lower_mergeable_stmt): Handle
bitint_extended == bitint_ext_full extension if needed.
(bitint_large_huge::lower_muldiv_stmt): Likewise.
(bitint_large_huge::lower_float_conv_stmt): Likewise.
* config/aarch64/aarch64.cc (aarch64_bitint_type_info): Set
info->extended to bitint_ext_undef rather than false.
* config/arm/arm.cc (arm_bitint_type_info): Set
info->extended to bitint_ext_full rather than true.
* config/i386/i386.cc (ix86_bitint_type_info): Set
info->extended to bitint_ext_undef rather than false.
* config/loongarch/loongarch.cc (loongarch_bitint_type_info): Set
info->extended to bitint_ext_partial rather than true.
* config/riscv/riscv.cc (riscv_bitint_type_info): Set
info->extended to bitint_ext_full rather than true.
* config/s390/s390.cc (s390_bitint_type_info): Likewise.
* gcc.dg/bitintext.h: Handle __riscv__ like __arm__.
* gcc.dg/torture/bitint-86.c: New test.
* gcc.dg/torture/bitint-87.c: New test.
Jason Merrill [Tue, 14 Apr 2026 17:49:52 +0000 (13:49 -0400)]
c++: mangling of extern "C" in anon ns [PR117133]
r15-3910 updated decl_linkage to return 'internal' for extern "C"
declarations in an anonymous namespace, as specified by C++11. This
unintentionally changed the result of unmangled_name_p for such variables,
though functions were unaffected.
The standard says that only variables with external linkage have language
linkage, but it doesn't say anything about name mangling for declarations
with internal linkage, so I think we might as well retain the old mangling
behavior. And then we don't need to document the mangling change.
I also notice that such variables still get global symbols, as
constrain_visibility still thinks that extern "C" takes priority, but let's
save fixing (and documenting) that for GCC 17.
Jason Merrill [Tue, 14 Apr 2026 23:19:37 +0000 (19:19 -0400)]
c++: unusual await_suspend parameters [PR123975]
expand_one_await_expression was assuming we could replace the last argument
of await_suspend with a call to handle::from_address. This is wrong if
either the handle parameter has a different type (123975) or await_suspend
has additional parameters (121643).
The change to pr105287.C is needed because that test now correctly calls
operator coroutine_handle<>(), and that addition confuses the analyzer into
thinking there's a use-after-free problem. Since the analyzer is known to
have a lot of trouble with coroutines (PR105382), let's ignore the new false
positive and just check that the test doesn't ICE.
Jason Merrill [Wed, 15 Apr 2026 04:51:22 +0000 (00:51 -0400)]
c++: coro return proxy that destroys [PR121961]
After the actor of simple() hits final_suspend and returns to the ramp, the
ramp returns the Wrapper variable holding the result of get_return_object,
which calls operator Result. Then we destroy the Wrapper, which calls
destroy() on the handle. Then we return to the ramp, and run the rest of
the cleanups.
Before this patch there were two bugs causing us to clean up the frame too
soon, in destroy(): First, the actor destroy() handling was unconditionally
cleaning up the frame rather than checking the refcount. Second, the ramp
was decrementing the refcount too soon.
PR c++/121961
gcc/cp/ChangeLog:
* coroutines.cc (build_actor_fn): Move the delete label before
the refcount handling.
(cp_coroutine_transform::build_ramp_function): Decrement refcount
after destroying gro.
projects / thirdparty / gcc.git / log
