Alice Carlotti [Tue, 21 Apr 2026 18:53:57 +0000 (19:53 +0100)]
aarch64 testsuite: Merge exts_sve2 into exts
Now that we support enabling +sme without +sve2, we no longer need to
include armv9-a when checking assembler support for SME extensions.
Merge exts_sve2 back into exts, and remove the separate handling for
exts_sve2. This is a partial revert of r16-2660-g9793ffce933234.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Merge exts_sve2 handling into exts.
Alice Carlotti [Tue, 21 Apr 2026 18:31:22 +0000 (19:31 +0100)]
aarch64 testsuite: Fix gating of sme-lutv2 asm tests
These tests were configured to try assembling whenever the assembler
supports sme2. Add dg-do directives to restrict this assemblers that
support sme-lutv2 (and otherwise just compile the test).
aarch64: PR124908 Fix ICE in svld1rq fold with -msve-vector-bits=128
svld1rq is a replicated-quadword load: it loads 16 bytes and
replicates them to fill the SVE register. When -msve-vector-bits=128
the instruction can be folded to a normal load.
The GIMPLE fold for svld1rq transforms the intrinsic into a 128-bit
memory load followed by a VEC_PERM_EXPR that replicates the loaded
value. When VL == 128, the VEC_PERM_EXPR becomes an identity
permutation. The checking assertion that validates the permutation
(can_vec_perm_const_p) fails for this degenerate case because the
vec_perm_const hook does not recognise the cross-mode identity
permutation (e.g. V16QI -> VNx16QI).
Fix by detecting when the SVE vector has the same number of elements as
the 128-bit quadword (known_eq (lhs_len, source_nelts)) and emitting a
VIEW_CONVERT_EXPR instead of a VEC_PERM_EXPR.
Bootstrapped and tested on aarch64-none-linux-gnu.
PR target/124908
* config/aarch64/aarch64-sve-builtins-base.cc
(svld1rq_impl::fold): When the SVE vector length equals the
quadword width, emit VIEW_CONVERT_EXPR instead of VEC_PERM_EXPR.
gcc/testsuite/ChangeLog:
PR target/124908
* gcc.target/aarch64/sve/acle/general/ld1rq_2.c: New test.
Jakub Jelinek [Wed, 22 Apr 2026 13:44:28 +0000 (15:44 +0200)]
Update crontab and git_update_version.py
2026-04-22 Jakub Jelinek <jakub@redhat.com>
maintainer-scripts/
* crontab: Snapshots from trunk are now GCC 17 related.
Add GCC 16 snapshots from the respective branch.
contrib/
* gcc-changelog/git_update_version.py (active_refs): Add
releases/gcc-16.
Jakub Jelinek [Wed, 22 Apr 2026 13:03:48 +0000 (15:03 +0200)]
c++, libstc++: Bump __cpp_impl_reflection and __cpp_lib_reflection
Both __cpp_impl_reflection and __cpp_lib_reflection were increased from
202506L to 202603L post Croydon, I assume to show that P3795R2 (maybe some
issues too) have been implemented.
Now, we do implement P3795R2 except for the is_applicable_type,
is_nothrow_applicable_type and apply_result metafunctions, but Jonathan says
there is agreement in LWG that to test for availability of those one should
test __cpp_lib_reflection >= 202603L && __cpp_lib_apply >= 202603L.
So, this patch bumps both FTMs.
2026-04-22 Jakub Jelinek <jakub@redhat.com>
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Bump __cpp_impl_reflection value
from 202506L to 202603L.
gcc/testsuite/
* g++.dg/DRs/dr2581-2.C: Adjust for __cpp_impl_reflection bump from
202506L to 202603L.
* g++.dg/reflect/feat1.C: Likewise. Also adjust for
__cpp_lib_reflection bump from 202506L to 202603L.
* g++.dg/reflect/feat2.C: Likewise.
* g++.dg/reflect/feat3.C: Likewise.
libstdc++-v3/
* include/bits/version.def (reflection): Bump 202506L to 202603L
for both v and in extra_cond.
* include/bits/version.h: Regenerate.
* include/std/meta: Compare __glibcxx_reflection against
202603L rather than 202506L.
* src/c++23/std.cc.in: Likewise.
Reviewed-by: Jason Merrill <jason@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Richard Earnshaw [Mon, 20 Apr 2026 15:57:22 +0000 (16:57 +0100)]
arm: fix mov<mode>_vfp_<mode>16 for fp16-only devs [PR124933]
We should only be using VLD1/VST1 instructions when we have an
auto-inc address of some suitable form and only when we have
NEON_FP16INST. At other times we should just use VLDR/VSTR. This
ensures that the code will assemble on targets that lack Advanced
SIMD. Also correct the constraint so that we can use offset
addressing on platforms that also have Neon.
gcc/ChangeLog:
PR target/124933
* config/arm/constraints.md (Uj): Allow offset addressing for
all targets, only allow Neon addressing when we have both Neon
and FP16INST.
* config/arm/vfp.md (mov<mode>_vfp_<mode>16): Only use vld1/vst1
when the pattern needs address write-back.
gcc/testsuite/ChangeLog:
PR target/124933
* lib/target-supports.exp (v8_1m_main_fp_hard): New arm
architecture variant.
* gcc.target/arm/pr124933.c: New test.
* gcc.target/arm/armv8_2-fp16-move-1.c: Update expected output.
Tomasz Kamiński [Wed, 22 Apr 2026 07:23:37 +0000 (09:23 +0200)]
libstdc++: Accept data_handle_type by value in mdspan deduction guide.
This makes the deduction guide accepting data_handle_type, mapping
and accessor consistent with corresponding constructor.
Resolves LWG4511.
libstdc++-v3/ChangeLog:
* include/std/mdspan (mdspan): Remove reference from
_AccessorType::data_handle_type parameteter of deduction
guide.
* testsuite/23_containers/mdspan/mdspan.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jakub Jelinek [Wed, 22 Apr 2026 05:56:38 +0000 (07:56 +0200)]
gensupport: Fix // comment handling [PR124971]
The while (*templ != '\n' || *templ != '\0') ++templ; loop
is due to a wrong logical operator an endless loop, so clearly
we don't have any // comments in the new syntax *.md files that
are using it in the relevant parts of the patterns.
Fixed by using && instead.
2026-04-22 Jakub Jelinek <jakub@redhat.com>
PR middle-end/124971
* gensupport.cc (convert_syntax): Fix up // comment handling.
Reviewed-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
The last patch made me try also pointer arithmetics on incomplete
type. And here we ICE before actually diagnosing the error
because we try to dereference element_size.
Furthermore, TYPE_SIZE_UNIT (element_type) is in sizetype, so
we shouldn't use build_one_cst (size_type_node) for the void *
case, but size_one_node (aka size_int (1)).
2026-04-22 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/124969
* c-typeck.cc (build_access_with_size_for_counted_by): Use
size_one_node instead of build_one_cst (size_type_node). Punt
if element_size is NULL_TREE.
Jakub Jelinek [Wed, 22 Apr 2026 05:52:25 +0000 (07:52 +0200)]
c-family: Fix ICE with counted_by attribute [PR124969]
The following valid testcase ICEs, because we try to use
TREE_CODE (NULL_TREE).
We document that counted_by is supported on pointers to void
and that it behaves like the GNU pointer to void arithmetics
extension in that case. build_access_with_size_for_counted_by
already uses 1 in that case as element_size.
The following patch fixes it, plus for error recovery punts
if it is a pointer to incomplete type other than void (pointer
arithmetics on such type will be diagnosed as error later on).
2026-04-22 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/124969
* c-ubsan.cc (get_index_from_pointer_addr_expr): For
VOID_TYPE_P (pointee_type) use size_one_node instead of
TYPE_SIZE_UNIT (pointee_type) as pointee_size. Punt for
!COMPLETE_OR_VOID_TYPE_P (pointee_type). Formatting fix. Use
CONVERT_EXPR_P (x) instead of CONVERT_EXPR_CODE_P (TREE_CODE (x)).
Jakub Jelinek [Wed, 22 Apr 2026 05:48:13 +0000 (07:48 +0200)]
testsuite: Xfails for aarch64/sme/streaming_mode_1.c and aarch64/sme/za_state_[12].c [PR122483]
This patch xfails some dg-errors in the tests and adds two xfailed
dg-bogus, so that we can downgrade this PR to P2 and defer resolution
hopefully for GCC 17.
2026-04-21 Jakub Jelinek <jakub@redhat.com>
PR target/122483
* gcc.target/aarch64/sme/streaming_mode_1.c: Xfail errors for
sc_a, sc_c, sc_e, s_a, s_c, s_e and keyword_contradiction_1.
* gcc.target/aarch64/sme/za_state_1.c: Xfail errors for shared_a,
shared_c, shared_e, preserved_a, preserved_c, preserved_e and
keyword_conflict_1.
* gcc.target/aarch64/sme/za_state_2.c: Xfail errors for shared_b,
shared_d, shared_f and shared_h. Add xfailed dg-bogus for
extra diagnostics on shared_f and shared_h.
These test-cases got typo-corrected in r16-8316-g630b53cd4ff1c3, which exposed them failing for
cris-elf. Though, at one time they were passing for the
right reason, and bisection shows they'd start failing when
the CRIS target was CC0-converted, and for the same reason
the S/390 32-bit fails. See the pre-existing comment in the
test and also see the PR for details, including a suggested
plan how to fix the optimization pass, if someone is
interested in an "easy hack". Though admittedly, the missed
optimization doesn't affect many targets.
Regarding the target pattern selector expression, I went for
the simplest possible, even though I'm including CRIS in the
64-bit exception.
Jason Merrill [Tue, 21 Apr 2026 20:23:37 +0000 (16:23 -0400)]
c++: #include rewrite and installed compiler [PR123879]
In an installed compiler, the pathname in the expanded_location might be
canonicalized while the pathname in the cpp_dir is not, e.g. eloc.file is
".../include/c++/16.0.1/stdbit.h" while dir->name is
".../lib/gcc/x86_64-pc-linux-gnu/16.0.1/../../../../include/c++/16.0.1". So
let's use lrealpath to compare canonical paths for both. And filename_ncmp,
while we're at it.
PR c++/123879
gcc/cp/ChangeLog:
* module.cc (maybe_translate_include): Use lrealpath in check
whether we're including something in the same directory.
allocator_traits<>::allocate_at_least has taken its allocator
by value, incorrectly. This patch makes it take its allocator
by reference, as specified.
libstdc++-v3/ChangeLog:
* include/bits/alloc_traits.h (allocate_at_least):
Take allocator argument by reference, per Standard.
`struct sock_fprog` is not provided by glibc, but rather by the linux
headers (`#include <linux/filter.h`). It seems that glibc due to an
implementation detail internally includes `<linux/filter.h>` somewhere
other C libs (e.g. musl) do not, which previously caused build failures
and let to disabling `struct sock_fprog` on non-glibc Linux systems.
This adds the missing include and provides it again for all Linux
systems regardless of C lib.
libsanitizer/ChangeLog:
PR sanitizer/124248
* sanitizer_common/sanitizer_platform_limits_posix.cpp (struct_sock_fprog_sz):
Make available on non-glibc Linux systems.
Jonathan Wakely [Tue, 21 Apr 2026 20:04:23 +0000 (21:04 +0100)]
libstdc++: Fix comment on std::print helper __open_terminal
The comment describes an earlier version of the function which I
experimented with when implementing the std::print feature. Update it to
describe the current semantics.
Jakub Jelinek [Tue, 21 Apr 2026 17:32:22 +0000 (19:32 +0200)]
c++: Parse splice-type-specifier in cp_parser_mem_initializer_id [PR124944]
The grammar has:
mem-initializer-id:
class-or-decltype
identifier
class-or-decltype:
nested-name-specifier[opt] type-name
nested-name-specifier template simple-template-id
computed-type-specifier
computed-type-specifier:
decltype-specifier
pack-index-specifier
splice-type-specifier
but we weren't parsing splice-type-specifier in there, just in
cp_parser_base_specifier. So, the following patch defers
similarly to cp_parser_base_specifier the typename diagnostics
because we don't know whether typename [: will be valid or not
- it could be splice-scope-specifier and in that case typename
is not valid, or splice-type-specifier, in which case it is valid
but not required. And calls cp_parser_splice_type_specifier too
when nested-name-specifier nor :: don't appear.
Jakub Jelinek [Tue, 21 Apr 2026 16:31:36 +0000 (18:31 +0200)]
c++: Fix up iterating expansion stmt b and e var handling [PR124927]
The following testcase ICEs, because the TARGET_EXPR it had has VOID_TYPE
TARGET_EXPR_INITIAL and force_target_expr obviously ICEs when trying to
create a VOID_TYPE TARGET_EXPR.
This patch fixes it by taking the cv_unqualified type of the TARGET_EXPRs
before we extract their TARGET_EXPR_INITIAL, so it does the desirable thing
of recreating the TARGET_EXPRs with cv unqualified types.
2026-04-21 Jakub Jelinek <jakub@redhat.com>
PR c++/124927
* pt.cc (finish_expansion_stmt): Compute types for force_target_expr
from b and e before extracting TARGET_EXPR_INITIAL from it.
Marek Polacek [Mon, 20 Apr 2026 19:55:50 +0000 (15:55 -0400)]
c++/reflection: bogus -Wmissing-field-initializers with <meta> [PR124950]
We emit -Wmissing-field-initializers warnings for code like
data_member_spec (^^int, { .name = "dms" })
which seems undesirable. We can initialize the members of
std::meta::data_member_options to suppress that warning (clang's <meta>
has these initializers too).
PR c++/124950
libstdc++-v3/ChangeLog:
* include/std/meta (std::meta::data_member_options): Initialize
alignment, bit_width, and annotations members.
Jonathan Wakely [Tue, 25 Nov 2025 14:29:50 +0000 (14:29 +0000)]
libstdc++: Use 32-bit platform wait type for OpenBSD and DragonFly [PR120527]
This defines __platform_wait_t as unsigned int for OpenBSD and
DragonFly. This means that std::semaphore will use unsigned int by
default, and so will benefit from more efficient wait/notify ops if we
start to use the OpenBSD futex(2) syscall or the DragonFly umtx(2)
syscalls. We don't currently use them, but if we start to in future, it
would be an ABI break to change __platform_wait_t later.
libstdc++-v3/ChangeLog:
PR libstdc++/120527
* include/bits/atomic_wait.h [__OpenBSD__ || __DragonFly]: Use
unsigned int for __platform_wait_t.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jonathan Wakely [Fri, 5 Dec 2025 15:47:10 +0000 (15:47 +0000)]
libstdc++: Add platform wait functions for Darwin [PR120527]
Darwin has kernel support for this facility from 10.12 (macOS Sierra).
From 10.15 (macOS Catalina) 64bit qualitities are supported.
When the library is built for 10.12+ both 32b and 64b quantities will be
supported by the DSO which means it can be installed on 10.12+ with support
for 64bit available when the instalation is >= 10.15.
The header will only recognise 64b quantities when the deployment version
is >= 10.15.
If the library is built for <= 10.11, the support will be missing and attempts
to use it wlll result in link errors.
The platform wait type is unconditionally set to 32bits, since this is compatible
across supported OS editions.
PR libstdc++/120527
libstdc++-v3/ChangeLog:
* include/bits/atomic_wait.h:
* src/c++20/atomic.cc (__ulock_wait): Enable supported Darwin versions.
(__ulock_wake): Likewise.
(UL_COMPARE_AND_WAIT): New.
(UL_COMPARE_AND_WAIT64): New.
(ULF_WAKE_ALL): New.
(_GLIBCXX_HAVE_PLATFORM_WAIT): Enable for suppported Darwin versions.
libstdc++: Implement P4012R1 while reverting P3844R2 (consteval simd broadcast)
P3844R2 added consteval conversion for value-preserving conversion from
constants. It had been approved by LEWG in Kona. Therefore, the current
implementation has the consteval broadcast constructor. In Croydon, LEWG
reversed the decision but changed the overload set to keep the design
space open for C++29.
This patch implements the removal of the consteval constructor and
changes the broadcast constructor according to P4012R1, to keep the
design space open.
libstdc++-v3/ChangeLog:
* include/bits/simd_details.h (__value_preserving_cast): Remove.
* include/bits/simd_mask.h (basic_mask): Replace plain 0 and 1
literals with cw<0> and cw<1>. Replace explicit basic_vec
construction from 0 and 1 with default init and broadcast from
_Up(1).
(_M_to_uint): Replace 1 with cw<1>.
* include/bits/simd_vec.h (basic_vec): Remove consteval
broadcast overload. Remove explicit broadcast from
non-value-preserving types.
* testsuite/std/simd/arithmetic.cc: Replace ill-formed integer
literals with explicit cast to T or use cw.
* testsuite/std/simd/mask.cc: Likewise.
* testsuite/std/simd/simd_alg.cc: Likewise.
* testsuite/std/simd/traits_common.cc: Adjust for resulting
traits changes.
* testsuite/std/simd/traits_math.cc: Likewise.
It turns out a union without an active member does not violate C++20 core
constant expression rules and r16-8748 was really just a workaround for a
front end bug. The actual underlying problem -- that the constexpr
evaluator treated an explicitly destroyed union member as still active --
has been fixed by r16-8767 which makes this workaround unnecessary for GCC.
Rather than remove the workaround, restrict it to Clang which seems to have
a similar bug making it still needed for e.g. the r16-8748 testcase.
PR c++/124910
libstdc++-v3/ChangeLog:
* include/std/optional (_Optional_payload_base::_M_destroy):
Restrict r16-8748 workaround to Clang, and adjust comment.
Jakub Jelinek [Tue, 21 Apr 2026 09:53:52 +0000 (11:53 +0200)]
bitintlower: Padding bit fixes, part 4 [PR123635]
As the following testcase shows, not clearing the padding bits after
signed MULT_EXPR (or signed division) is reasonable when overflow actually is
undefined behavior because then anything can happen. But when it is not
undefined behavior due to -fwrapv, we need to clear the padding bits
on targets which chose that behavior. It isn't only signed MULT_EXPR,
but also division because smallest negative / -1 overflows and in that
case the padding bits aren't correct for bitint_extended targets either.
2026-04-21 Jakub Jelinek <jakub@redhat.com>
PR middle-end/123635
* gimple-lower-bitint.cc (bitint_large_huge::lower_muldiv_stmt):
Extend the padding bits not just for unsigned MULT_EXPR but for any
TYPE_OVERFLOW_WRAPS MULT_EXPR and signed TYPE_OVERFLOW_WRAPS division.
Jakub Jelinek [Tue, 21 Apr 2026 09:49:23 +0000 (11:49 +0200)]
sccvn: Use build_bitint_type in another SCCVN spot [PR124941]
The following testcase ICEs on riscv.
tree-ssa-sccvn.cc (vn_walk_cb_data::push_partial_def) already uses
build_bitint_type instead of build_nonstandard_integer_type for larger
BITINT_TYPE types:
/* Make sure to interpret in a type that has a range covering the whole
access size. */
if (INTEGRAL_TYPE_P (vr->type) && maxsizei != TYPE_PRECISION (vr->type))
{
if (TREE_CODE (vr->type) == BITINT_TYPE
&& maxsizei > MAX_FIXED_MODE_SIZE)
type = build_bitint_type (maxsizei, TYPE_UNSIGNED (type));
else
type = build_nonstandard_integer_type (maxsizei, TYPE_UNSIGNED (type));
}
and the same change in vn_reference_lookup_3 fixes the ICE.
2026-04-21 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/124941
* tree-ssa-sccvn.cc (vn_reference_lookup_3): Use build_bitint_type
rather than build_nonstandard_integer_type for
maxsizei larger than MAX_FIXED_MODE_SIZE.
Paul Thomas [Tue, 21 Apr 2026 14:00:14 +0000 (15:00 +0100)]
Fortran: ICE due to allocatable component in hidden type [PR117077]
2026-03-19 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/117077
* trans-expr.cc (gfc_trans_scalar_assign): If the lhs and rhs
TYPE_MAIN_VARIANTs are not the same, convert the rhs to the lhs
type via a VIEW_CONVERT_EXPR.
gcc/testsuite/
PR fortran/117077
* gfortran.dg/pr117077.f90: New test.
commit 14cd2833b27a9700aa8679fd0a090e8ae7a5f44a added xfails, but
2025-12-05's Richard Biener <rguenther@suse.de>'s PR
tree-optimization/120939 patch to skip gcc.dg/torture/pr113026-1.c
when -ftracer had already taken care of them without XPASSes.
for gcc/testsuite/ChangeLog
PR tree-optimization/113524
* gcc.dg/torture/pr113026-1.c: Revert 2026-01-21's
XFAIL of bogus warning on various 32-bit targets.
Changes to arm_v8_3a_complex_neon options and to
vect_complex_add_{float,double} enabled these tests and caused them to
fail with the same failure mode as -half-float.c, namely, reassoc
makes ADD_ROT270 unrecognizable in fms_elemconjsnd after complex
lowering and dce's removal of the original complex assignments.
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:
projects / thirdparty / gcc.git / log
