Alexandre Oliva [Fri, 19 Dec 2025 07:57:05 +0000 (04:57 -0300)]
[lra] take scratch as implicit unused output reloads [PR55212]
When trying to convert the SH port to use LRA, the first issue I hit
was the need for dealing with former scratch registers at places we
didn't need to on other ports, treating them like unused output
reloads instead of rejecting them.
for gcc/ChangeLog
PR target/55212
* lra-constraints.cc (match_reload): Treat former scratch
regs as implicit unused output reloads.
(process_alt_operands): Likewise.
(curr_insn_transform): Likewise.
Nathaniel Shead [Sat, 6 Dec 2025 05:47:18 +0000 (16:47 +1100)]
c++/modules: Reattempt to complete ARRAY_TYPEs after reading a cluster [PR122922]
The PR raises an issue where we complain about value-initializing an
incomplete array type, where the element type is a complete type.
Here, the friend declaration brings TTensor<0> and TTensor<1> into the
same cluster, and we have no intra-cluster ordering that ensures
TTensor<0>'s definition is streamed before TTensor<1>'s definition is.
In general we don't currently do any ordering of definitions, we only
reorder in cases that a declaration depends on another.
In this particular case we happen to stream TTensor<1>'s definition
first, which builds an array type of TTensor<0>. At this point
TTensor<0>'s definition hasn't been streamed, so the array is considered
to be an array of incomplete type. Later we do stream TTensor<0>'s
definition, but we don't update the TYPE_SIZE etc. of the array type we
built earlier so build_value_init thinks we still have incomplete type
and errors.
Some possible approaches:
1. Have some post-processing for arrays of incomplete type during module
streaming; once we've finished reading the cluster we can loop
through those array types and attempt to complete them.
2. Add a dependency ordering between structs that have a field that's a
non-dependent array type of a different struct in the same cluster,
so that the latter is always streamed first. We shouldn't see cycles
because we cannot have two structs with arrays of each other. This
would require processing definitions though and I'm not convinced
this necessarily would fix the issue in all cases.
3. Add more calls to 'complete_type' when processing structure fields,
rather than assuming that if we have a complete record type all its
fields must also have been completed already. This seems error-prone
though, as we may miss cases. Unless perhaps we replace uses of
COMPLETE_TYPE_P entirely in the C++ frontend with a function that
attempts to complete the type and returns false if it failed?
This patch takes approach #1 as a minimal fix, but maybe it would be
worth exploring other approaches later.
PR c++/122922
gcc/cp/ChangeLog:
* module.cc (trees_in::post_types): New member.
(trees_in::trees_in): Initialize it.
(trees_in::~trees_in): Clean it up.
(trees_in::post_process_type): New functions.
(trees_in::tree_node): Save incomplete ARRAY_TYPEs for later
post-processing.
(module_state::read_cluster): Attempt to complete any
ARRAY_TYPEs we saved earlier.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr122922_a.C: New test.
* g++.dg/modules/pr122922_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Nathaniel Shead [Thu, 4 Dec 2025 14:14:36 +0000 (01:14 +1100)]
c++/modules: Don't build STAT_HACKs for current TU namespace bindings [PR122995]
The issue in the PR is that we're checking if the binding entity for the
current TU matches the namespace we're pushing. In this case the slot
however is a STAT_HACK we created during 'maybe_record_mergeable_decl'
to indicate that the binding entity contains a global module binding.
Adding '|| (STAT_HACK_P ((tree) slot) && STAT_DECL ((tree) slot) == ns)'
should fix the assertion, but I think we want to just not build the
STAT_HACK for namespaces, as they'll always be global module regardless,
and cannot match with any other declaration, so there's no need for the
special flag.
PR c++/122995
gcc/cp/ChangeLog:
* name-lookup.cc (maybe_record_mergeable_decl): Don't build a
STAT_HACK for namespaces.
gcc/testsuite/ChangeLog:
* g++.dg/modules/namespace-17_a.C: New test.
* g++.dg/modules/namespace-17_b.C: New test.
Lewis Hyatt [Tue, 16 Dec 2025 05:15:14 +0000 (00:15 -0500)]
configure: Support disabling specific languages [PR12407]
Sometimes it can be desirable to get the semantics of
--enable-languages=all, but to exclude one or more languages from the
build. Currently this is not directly supported; the best you can do is to
list the ones you do want to be built as arguments to --enable-languages.
In addition to being inconvenient, this also complicates cross-platform
portability, since --enable-languages=all carries the useful semantics that
unsupported languages will be skipped automatically; by contrast, languages
listed explicitly as arguments to --enable-languages will produce a hard
error if they are not supported.
This patch extends the syntax of --enable-languages so that, e.g.:
--enable-languages=all,^xyz,^abc
would build every supported language other than xyz and abc.
ChangeLog:
PR bootstrap/12407
* configure.ac: Add feature to parsing of --enable-languages so that
a language can be disabled by prefixing it with a caret.
* configure: Regenerate.
gcc/ChangeLog:
PR bootstrap/12407
* doc/install.texi (--enable-languages): Document the new language
exclusion feature.
LIU Hao [Wed, 3 Dec 2025 03:10:46 +0000 (11:10 +0800)]
libstdc++: On Windows, retrieve thread-local variables via functions
For Windows, GCC can be configured with `--enable-tls` to enable native TLS.
The native TLS implementation has a limitation that it is incapable of
exporting thread-local variables from DLLs. Therefore, they are retrieved
via getter functions instead.
libstdc++-v3/ChangeLog:
* config/os/mingw32-w64/os_defines.h (_GLIBCXX_NO_EXTERN_THREAD_LOCAL):
New macro.
* include/std/mutex [_GLIBCXX_NO_EXTERN_THREAD_LOCAL]
(__get_once_callable, __get_once_call): Declare new functions.
* src/c++11/mutex.cc [_GLIBCXX_NO_EXTERN_THREAD_LOCAL]
(__get_once_callable, __get_once_call): Define.
Signed-off-by: LIU Hao <lh_mouse@126.com> Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
Add the assumption clause 'no_openmp_constructs' (which as most assumption
clauses is ignored in the front end - for now).
For Fortran, improve free-form parsing of argument-free clauses
by avoiding substring matches.
Patrick Palka [Thu, 18 Dec 2025 19:24:54 +0000 (14:24 -0500)]
c++: restore printing 'typename' for none_type tag
The drive-by change in r16-6144 to have dump_type not print any tag name
for none_type TYPENAME_TYPE caused some diagnostic regressions in C++20
mode where an expected 'typename' is now missing in the error message:
g++.dg/concepts/diagnostic5.C (test for warnings, line 5)
g++.old-deja/g++.pt/typename3.C (test for errors, line 20)
g++.old-deja/g++.pt/typename4.C (test for errors, line 25)
g++.old-deja/g++.pt/typename6.C (test for errors, line 18)
The first test shows we no longer print 'typename' when diagnosing a
failed type-requirement:
• in requirements [with T = char]
gcc/testsuite/g++.dg/concepts/diagnostic5.C:5:16:
5 | concept c1 = requires { typename T::blah; };
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
• the required type ‘T::blah’ is invalid
which is undesirable since 'typename' has been explicitly written.
(The other three tests are less interesting since they're error-recovery.)
The TYPENAME_TYPE in question is being built with a none_type tag due
to cp_parser_type_name passing tag_type=none_type to cp_parser_class_name.
This seems wrong at least when typename_keyword_p=true. But rather than
continue messing with this old and delicate part of the parser, this patch
just restores printing the 'typename' prefix for none_type TYPENAME_TYPEs.
gcc/cp/ChangeLog:
* decl.cc (tag_name) <case none_type>: Return "typename" as if
typename_type.
This change causes ICE e.g. on the following testcase.
The problem is that build_typename_type expects IDENTIFIER_NODE as the
second argument, e.g. it uses it as
tree d = build_decl (input_location, TYPE_DECL, name, t);
argument. But TYPE_NAME doesn't have to be an IDENTIFIER_NODE, it can
be a TYPE_DECL too and when we build a TYPE_DECL with TYPE_DECL as
DECL_NAME, it breaks all kinds of assumptions everywhere in the FE as well
as middle-end.
Fixed by using TYPE_IDENTIFIER instead.
2025-12-18 Jakub Jelinek <jakub@redhat.com>
PR c++/123186
* parser.cc (cp_parser_template_id): Use TYPE_IDENTIFIER instead of
TYPE_NAME in second build_typename_type argument.
Egas Ribeiro [Sat, 13 Dec 2025 13:14:47 +0000 (13:14 +0000)]
c++: Fix ICE with type aliases in inherited CTAD [PR122070]
When processing inherited CTAD in C++23, type_targs_deducible_from can
be called with a synthetic alias template whose TREE_VALUE is a type
alias. Since TYPE_TEMPLATE_INFO_MAYBE_ALIAS can return NULL for type
aliases, we need to fall back to TYPE_TEMPLATE_INFO to get the template
info of the underlying type before calling TI_TEMPLATE, which should
always be non-NULL when called from inherited_ctad_tweaks.
PR c++/122070
gcc/cp/ChangeLog:
* pt.cc (type_targs_deducible_from): Fall back to
TYPE_TEMPLATE_INFO when TYPE_TEMPLATE_INFO_MAYBE_ALIAS is NULL.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/class-deduction-inherited10.C: New test.
* g++.dg/cpp23/class-deduction-inherited9.C: New test.
Signed-off-by: Egas Ribeiro <egas.g.ribeiro@gmail.com> Co-authored-by: Patrick Palka <ppalka@redhat.com> Reviewed-by: Patrick Palka <ppalka@redhat.com>
Jonathan Wakely [Thu, 18 Dec 2025 10:38:31 +0000 (10:38 +0000)]
libstdc++: Fix ranges::stable_sort handling of null buffer [PR123180]
The logic of the null pointer check got reversed when converting the
std::stable_sort code for ranges::stable_sort.
libstdc++-v3/ChangeLog:
PR libstdc++/123180
* include/bits/ranges_algo.h (__stable_sort_fn::operator()): Fix
sense of null check. Replace typedef with alias-declaration.
* testsuite/25_algorithms/stable_sort/123180.cc: New test.
This patch enables ACLE macro __ARM_FEATURE_SVE_PREDICATE_OPERATORS to indicate
that C/C++ language operations are available natively on SVE ACLE type svbool_t.
* gcc.target/aarch64/sve/acle/general/attributes_1.c: Update test for
__ARM_FEATURE_SVE_PREDICATE_OPERATORS.
* gcc.target/aarch64/sve/acle/general/attributes_9.c: New.
Given that profile probability is computed as an unsigned integer
value in the [0, max_probability = (uint32_t) 1 << (n_bits - 2)]
range (as opposed to a [0, 1] float), 50/50 likeihoods are encoded as
`even()', mapping to `max_probability / 2'.
The previous use of 0.5 for an even probability was, as a consequence
of the implicit `double' -> `uint32_t' conversion, silently set to 0 by
GCC when not using the `-Wconversion' flag.
We therefore replace the erroneous `probability (0.5, GUESSED)'
initialization with its correct `profile_probability::even ()'
counterpart.
gcc/ChangeLog:
PR tree-optimization/123153
* tree-vect-loop-manip.cc
(slpeel_tree_duplicate_loop_to_edge_cfg): use
profile_probability::even () for even likelihood.
Jonathan Wakely [Wed, 17 Dec 2025 18:36:36 +0000 (18:36 +0000)]
libstdc++: Fix up std::generate_canonical for 32-bit arches
Make use of __detail::_Select_uint_least_t<d>::type for
std::generate_canonical, so that we choose an appropriately sized
integer based on the number of bits needed, and so we have a 128-bit
integer type even on 32-bit targets (via the new __rand_uint128 class).
libstdc++-v3/ChangeLog:
* include/bits/random.tcc (__generate_canonical_pow2): Adjust
comments. Remove _UInt template parameter and define it in the
body using _Select_uint_least_t<__d>. Remove popcount call for
getting the width of the _UInt type. Cast floating-point
literal to _RealT.
(__generate_canonical_any): Remove _UInt template parameter and
define it in the body using _Select_uint_least_t<__d * 2>. Use
direct-initialization for _UInt variables. Cast floating-point
literal to _RealT.
(generate_canonical): Remove unused typedef. Remove constexpr-if
branches and remove unsigned type from template argument lists.
Co-authored-by: Jakub Jelinek <jakub@redhat.com> Reviewed-by: Nathan Myers <nmyers@redhat.com>
Alfie Richards [Wed, 29 Oct 2025 13:29:10 +0000 (13:29 +0000)]
aarch64: Add new target options for 2024 Architecture Extension and Armv9.6-A
This does not add support for these version (and the corresponding
__ARM_FEATURE_<X> macros aren't implemented for this reason) but
accepts the command line strings and allows these to be passed on to
the assembler.
Armv9.6-A is supported by the new "armv9.6-a" option and defined as
"armv9.5-a+cmpbr+lsui+occmo"
Alfie Richards [Wed, 29 Oct 2025 13:29:10 +0000 (13:29 +0000)]
aarch64: Split sve2-X extensions into sve2 + sve-X extension.
Changes the "sve2-sm4", "sve2-sha3", "sve2-bitperm", and "sve2-aes"
to be aliases which imply both "sve2" and the new option "sve-sm4",
"sve-sha3", "sve-bitperm", or "sve-aes" respectively.
The EXPLICIT_OFF values are chosen to preserve the existing behaviour of
+nosve2-X.
This granularity is needed to model the 2024 Architecture Extensions
dependencies.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def
(sve-aes): New cli extension option.
(sve2-aes): Changed to be alias of sve2+sve-aes2.
(sve-bitperm): New cli extension option.
(sve2-bitperm): Changed to be alias of sve2+sve-bitperm.
(sve-sm4): New cli extension option.
(sve2-sm4): Changed to be alias of sve2+sve-sm4.
(sve-sm4): New cli extension option.
(sve2-sm4): Changed to be alias of sve2+sve-sm4.
* config/aarch64/aarch64.h (TARGET_SVE2_AES): Updated to require
sve2+sve-aes.
(TARGET_SVE2_BITPERM): Updated to require sve2+sve-bitperm.
(TARGET_SVE2_SHA3): Updated to require sve2+sve-sha3.
(TARGET_SVE2_SM4): Updated to require sve2+sve-sm4
* config/aarch64/aarch64-sve-builtins-sve2.def: Update gating for sve2-X
intrinsics.
Alfie Richards [Wed, 12 Nov 2025 16:30:45 +0000 (16:30 +0000)]
aarch64: Add alias option support
Adds the AARCH64_OPT_EXTENSION_ALIAS macro to aarch64-option-extensions.def
to define architecture features which gate no features themselves, but
act as aliases for other features.
When getting the extension string for some architecture flags, alias features
should be used over their constituent features, even if some of the constituent
features are enabled transitively by other features.
Changes +crypto option to use this macro.
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc
(struct aarch64_extension_info): Add flags_alias_preferred_over.
(AARCH64_OPT_EXTENSION): Add setting flags preferred over to 0.
(AARCH64_OPT_EXTENSION_ALIAS): New macro def.
(aarch64_get_extension_string_for_isa_flags): Update to use alias
extensions over constituent extensions.
* config/aarch64/aarch64-feature-deps.h (alias_flags): New variable
(AARCH64_OPT_EXTENSION): New macro def.
(AARCH64_OPT_EXTENSION_ALIAS): New macro def.
(HANDLE): Update to use alias_flags.
(AARCH64_CORE): Update to use alias_flags.
* config/aarch64/aarch64-option-extensions.def
(AARCH64_OPT_EXTENSION_ALIAS): New macro def to
define alias_prefer_over_flags_X.
(crypto): Update to us AARCH64_OPT_EXTENSION_ALIAS.
chenxiaolong [Thu, 11 Dec 2025 02:49:05 +0000 (10:49 +0800)]
LoongArch: Add support for the TARGET_MODES_TIEABLE_P vectorization type.
v1->v2:
Add the TARGET_MODES_TIEABLE_P function description and analyze the
reasons for the cost change of Subreg type rtx after supporting
vectorization.
This hook returns true if a value of mode mode1 is accessible in mode
mode2 without copying. On LA, for vector types V4SF and V8SF, the lower
128 bit data can be shared. After adding vector support in this hook,
the cost of type conversion for the subreg operation from the V4SF to
the V8SF registers can be made zero, and some rtx optimization
operations can be completed in the combine traversal. The comparison
of the backend support vectors before and after is as follows:
* config/loongarch/loongarch.cc (loongarch_modes_tieable_p):
Add support for vector conversion.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/vector/lasx/vect-extract-256-128.c:
After supporting the vectorized type corresponding to subreg in
the backend, the cost of rtx becomes 0. In fwprop1 pass,
memory-loaded rtx cannot be propagated to this insn, which leads
to xvld not being optimized into vld instructions.
* gcc.target/loongarch/vect-mode-tieable.c: New test.
Richard Biener [Wed, 17 Dec 2025 13:38:23 +0000 (14:38 +0100)]
c/123156 - overflow in shuffle mask for __builtin_shufflevector
At some point the permute vector element type had to match the value
elemnt in size which easily leads to overflow for char element types
as shown in the testcase. This was relaxed for constant permute
masks, so use ssizetype.
PR c/123156
gcc/c-family/
* c-common.cc (c_build_shufflevector): Use ssizetype for the
permute vector element type.
gcc/testsuite/
* gcc.dg/torture/builtin-shufflevector-pr123156.c: New testcase.
Do not skip jobserver flags with negative file descriptors
As part of jobserver detection, the jobserver_info constructor looks
for the last occurence of "--jobserver-auth=", and parses the argument
for that option to look for either a named pipe (has a "fifo:" prefix)
or read and write pipe fds separated by a comma.
With GNU Make 4.4 and above, named pipes are used by default because
anonymous pipe fds cannot be used reliably (see
https://savannah.gnu.org/bugs/?57242), but it still supports a
--jobserver-style=pipe option for compatibility reasons. With that
flag enabled, or with older GNU Make versions, the jobserver detection
code checks if the provided fds are greater than 0 and valid. If
invalid, it drops them from MAKEFLAGS used for subsequent child
processes.
However, GNU Make explicitly provides negative jobserver pipe fds if
the command is not marked as recursive (i.e is missing a '+' prefix in
the Makefile) - see https://savannah.gnu.org/bugs/?57242#comment13.
The MAKEFLAGS look like this in that case.
-j4 --jobserver-auth=3,4 --jobserver-auth=-2,-2
Stripping off the final --jobserver-auth with negative fds undoes this
helpful hint from GNU Make, and exposes child processes (like
lto-wrapper) to all the issues with anonymous pipe fds that forced GNU
Make to switch to named pipes by default.
This patch prevents that stripping if jobserver communication is *not*
via a named pipe *and* file descriptors are negative. As a result,
child processes receive MAKEFLAGS with negative file descriptors too,
and correctly decide that a jobserver is not available.
gcc/ChangeLog:
* opts-common.cc (jobserver_info::jobserver_info): Do not skip
negative file descriptors in simple UNIX pipe mode.
Andrew Pinski [Mon, 15 Dec 2025 20:36:44 +0000 (12:36 -0800)]
ch: Fix detection of non-executed loop exit
After r16-6104-gb5c64db0a49d46, we try to duplicate bb's
that contain loop exit that have "never exit" but we check
against the propability of the exit to very_unlikely. If we
have PGO, then a loop exit might be very unlikely to be taken
if we interate the loop more than 2000 times.
The problem is the check for very_unlikely is just wrong. It should
just be never. So let's remove that.
Also adds a testcase for __builtin_abort instead of __builtin_unreachable
since there are slightly different pathes to get the probilities.
Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/122734
gcc/ChangeLog:
* tree-ssa-loop-ch.cc (should_duplicate_loop_header_p): Remove
check on very_unlikely probability.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/copy-headers-13.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Andrew Pinski [Wed, 17 Dec 2025 00:04:18 +0000 (16:04 -0800)]
predict: Fix return value in unlikely_executed_stmt_p for __builtin_unreachable/__builtin_trap
Looks like Honza messed up the return value for __builtin_unreachable/__builtin_trap
in unlikely_executed_stmt_p (with r16-2639-g1d3e713dda99e2). These are inserted
by the user or optimizers but they are always unlikely. So fix the return value
to be true for these.
A minor update to gcc.target/i386/pr121572-1a.c is needed as the never executed
predicate causes the trap instruction (ud2) to be in a new partition which interfers
with the dg-final check-body check. Also the code generation goes back to what it
was in GCC 15 also.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* predict.cc (unlikely_executed_stmt_p): Fix up return for
__builtin_unreachable/__builtin_trap.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr121572-1a.c: Turn off -freorder-blocks-and-partition
as it interferes with the check-body.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Alexandre Oliva [Thu, 18 Dec 2025 01:41:14 +0000 (22:41 -0300)]
vartrack: fix skipping of unsuitable locs
When the last loc in a chain happens to be an unsuitable_loc(), we
record VAR_LOC_FROM as if the empty location had been derived from
that unsuitable loc, instead of leaving it empty, which ends up
preventing the VAR loc from being recomputed when other related locs
are usefully expanded.
Adjust the code that skips an unsuitable_loc() to take the same
preparation steps we take for exiting the loop as when an expansion
attempt yields NULL_RTX.
for gcc/ChangeLog
* var-tracking.cc (vt_expand_var_loc_chain): Prepare to exit
the loop after unsuitable_loc.
Jonathan Wakely [Tue, 16 Dec 2025 11:12:33 +0000 (11:12 +0000)]
libstdc++: Make __cpp_lib_constexpr_exceptions depend on cxx11 ABI
The COW std::string is not constexpr, so the <stdexcept> exception
classes can't be constexpr either when they're defined in terms of the
COW string.
While constexpr exceptions for <typeinfo>, <new>, and <exception>
classes would work, __cpp_constexpr_exceptions >= 202411L implies that
everything including <stdexcept> should work. So when we can't support
it fully, we shouldn't announce it.
libstdc++-v3/ChangeLog:
* include/bits/version.def (constexpr_exceptions): Add
cxx11abi=yes.
* include/bits/version.h: Regenerate.
* testsuite/18_support/exception/version.cc: Require effectiove
target cxx11_abi.
* testsuite/18_support/exception_ptr/exception_ptr_cast.cc: Only
check for constexpr support in cxx11 ABI.
* testsuite/19_diagnostics/headers/stdexcept/version.cc: Require
effective target cxx11_abi.
* testsuite/19_diagnostics/logic_error/constexpr.cc: Likewise.
* testsuite/19_diagnostics/runtime_error/constexpr.cc: Likewise.
* testsuite/20_util/expected/version.cc: Only check for
__cpp_lib_constexpr_exceptions macro for cxx11 ABI.
* testsuite/20_util/optional/version.cc: Likewise.
* testsuite/20_util/variant/version.cc: Likewise.
Jonathan Wakely [Wed, 17 Dec 2025 12:42:12 +0000 (12:42 +0000)]
libstdc++: Implement std::philox_engine for targets without __int128
This moves the __detail::_Select_uint_least_t<N>::type class to
namespace scope and extends it with more 128-bit arithmetic operations,
implemented in terms of uint64_t.
Now std::philox_engine can use _Select_uint_least_t<w*2>::type instead
of __uint128_t, so that it works on targets without 128-bit integers.
This also means that targets that do support __uint128_t only use it
when actually necessary, so that we use uint64_t when generating a
32-bit result (e.g. with std::philox4x32).
libstdc++-v3/ChangeLog:
* include/bits/random.h [!__SIZEOF_INT128__] (__rand_uint128):
Refactor and rename _Select_uint_least_t<128>::type to a new
class. Make all members constexpr. Add new member functions for
additional arithmetic and bitwise operations, and comparisons.
(__detail::_Select_uint_least_t<>::type): Define as an alias of
__rand_uint128.
* include/bits/random.tcc (philox_engine::_M_mulhi): Use
_Select_uint_least_t<w*2>::type instead of __uint128_t.
(philox_engine::_M_transition): Likewise.
* include/bits/version.def (philox_engine): Remove extra_cond.
* include/bits/version.h: Regenerate.
* testsuite/26_numerics/random/philox4x32.cc: Remove
dg-require-cpp-feature-test directive.
* testsuite/26_numerics/random/philox4x64.cc: Likewise.
* testsuite/26_numerics/random/philox_engine/cons/copy.cc:
Likewise.
* testsuite/26_numerics/random/philox_engine/cons/default.cc:
Likewise.
* testsuite/26_numerics/random/philox_engine/cons/seed.cc:
Likewise.
* testsuite/26_numerics/random/philox_engine/operators/equal.cc:
Likewise.
* testsuite/26_numerics/random/philox_engine/operators/serialize.cc:
Likewise.
* testsuite/26_numerics/random/philox_engine/requirements/constants.cc:
Likewise.
* testsuite/26_numerics/random/philox_engine/requirements/typedefs.cc:
Likewise.
Co-authored-by: Jakub Jelinek <jakub@redhat.com> Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jonathan Wakely [Wed, 17 Dec 2025 19:39:39 +0000 (19:39 +0000)]
libstdc++: Use -fexcess-precision=standard for std::generate_canonical tests
On 32-bit x86 the default -fexcess-precision=fast setting used by
-std=gnu++20 results in unpredictable rounding which alters the number
of times that std::generate_canonical produces exactly 1.0f, which
means that the URBG is invoked a different number of times.
To ensure that the behaviour is consistent and the expected number of
calls happens, use -fexcess-precision=standard.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/uniform_real_distribution/operators/64351.cc:
Add -fexcess-precision=standard to options.
* testsuite/26_numerics/random/uniform_real_distribution/operators/gencanon.cc:
Likewise.
Jonathan Wakely [Wed, 17 Dec 2025 13:58:21 +0000 (13:58 +0000)]
libstdc++: Adjust tests to work for -D_GLIBCXX_USE_OLD_GENERATE_CANONICAL
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/uniform_real_distribution/operators/64351.cc
[_GLIBCXX_USE_OLD_GENERATE_CANONICAL]: Restore test01. Do not discard an
extra value in test02.
* testsuite/26_numerics/random/uniform_real_distribution/operators/gencanon.cc:
Skip if _GLIBCXX_USE_OLD_GENERATE_CANONICAL is defined in options.
Gaius Mulley [Wed, 17 Dec 2025 17:02:09 +0000 (17:02 +0000)]
PR modula2/23178: reduce error message clutter when reporting a non procedure
This bug fix corrects the token of an error message when reporting
about a symbol which was not exported from a definition module.
The reimplemented procedure CheckCanBeImported uses MetaError2
with the spell hint format specifier if the symbol is unknown
rather than the older WriteFormat2 procedure.
gcc/m2/ChangeLog:
PR modula2/23178
* gm2-compiler/P3SymBuild.mod (CheckCanBeImported): Reimplement to
use MetaError2 and provide spell hints if possible for unknown symbols.
gcc/testsuite/ChangeLog:
PR modula2/23178
* gm2/pim/fail/badprocedure.mod: New test.
Georg-Johann Lay [Tue, 16 Dec 2025 19:49:31 +0000 (20:49 +0100)]
AVR: Tweak shift execution times in some cases.
When the tail reg (last register) in a shift is an upper register,
then inserting a sequence of 0s and a 1 into the tail register
only takes 2 instruction. The preparation will be one instruction
longer, but the loop body will be one instruction shorter, saving
count-1 cycles.
andi r22,-32 ; Set lower 5 bits to 0.
ori r22,16 ; Set bit 4 to 1.
;; Now r22 = 0b***10000
1: lsr r25
ror r24
ror r23
ror r22
brcc 1b ; Carry will be 0, 0, 0, 0, 1.
gcc/
* config/avr/avr.cc (avr_out_shift_with_cnt): Tweak
execution time by count-1 cycles in some cases.
Ulrich Weigand [Wed, 17 Dec 2025 16:36:56 +0000 (17:36 +0100)]
Fix testsuite/123166 - add missing dg-do run
The patch I committed a few years ago to remove SPU support
https://gcc.gnu.org/pipermail/gcc-patches/2019-September/529052.html
accidentally completely removed the { dg-do run } annotations
in four gfortran.dg test cases. Add them back.
Jeff Law [Wed, 17 Dec 2025 16:08:09 +0000 (09:08 -0700)]
Fix various RISC-V testsuite regressions after volatile patch
The RISC-V port showed a handful of regressions after integrating the final
patch from HJ for volatile accesses.
The core issue is the RISC-V port has two patterns which are basically the same
RTL form with the exception of a clobber of a scratch operand.
Those patterns do differ materially in their condition in that one is more
strict than the other. The pattern with the stricter condition also happens to
be the one without the clobber. So it's clearly stricter across both of those
axis.
The stricter pattern naturally generates more efficient (loopless) code for the
relevant atomic operations. We have a handful of tests in the RISC-V port
which verify that we use the right sequences.
With HJ's patch the insn gets re-matched during combine which adds the clobber
and ultimately matches the more general pattern (which is currently first in
the MD file). So we end up with the less efficient sequence and the relevant
tests naturally fail.
This patch just puts the two patterns in the right order with the stricter
pattern coming first. I also walked through the rest of the sync.md patterns
and none obviously had the same problem.
This has been bootstrapped and regression tested on risc-v with both the
Pioneer and BPI F3 systems.
I'll let pre-commit CI chew on it overnight before the planned commit tomorrow.
jeff
gcc/
* config/riscv/sync.md (atomic compare and set): Reorder patterns
so the stricter pattern comes first.
benwu25 [Wed, 17 Dec 2025 13:54:00 +0000 (20:54 +0700)]
c++: adjust comment wording in cp_parser_init_declarator
It seems likely the original author meant to use either "and" or "for"
in this comment rather than both. We can remove the "for" to make it
slightly more clear that the declarator for the function-definition
and everything left in the function-definition would be handled here.
Jonathan Wakely [Wed, 17 Dec 2025 10:17:37 +0000 (10:17 +0000)]
libstdc++: Move new std::generate_canonical to inline namespace
This ensures that the new definition of std::generate_canonical has a
different mangled name from the old one, so that TUs compiled with GCC
16 will be sure to use the new definition, even if the linker also sees
a symbol instantiated from the old definition. We use the same _V2
inline namespace as used elsewhere (std::_V2::condition_variable,
std::_V2::__rotate, and std::chrono::_V2::system_clock), and use a macro
to add it conditionally so that it's not used for the ABI-unstable
gnu-versioned-namespace configuration.
We can simplify the 26_numerics/random/pr60037-neg.cc test to only use
one dg-error without a line number, so that it matches any of the three
relevant static_assert failures for this test: the one from _Adaptor in
<bits/random.h> and the ones from the new and old definitions of
std::generate_canonical in <bits/random.tcc>. Without this change, the
line number for the dg-error matching the <bits/random.tcc> error
depends on the _GLIBCXX_USE_OLD_GENERATE_CANONICAL macro, which is
awkward to depend on in the test (because DejaGnu sees all dg-error
directives, it doesn't care if they're guarded by #ifdef preprocessor
checks).
libstdc++-v3/ChangeLog:
* include/bits/random.h [!_GLIBCXX_USE_OLD_GENERATE_CANONICAL]
(generate_canonical): Use inline namespace _V2.
* include/bits/random.tcc [!_GLIBCXX_USE_OLD_GENERATE_CANONICAL]
(generate_canonical): Likewise.
* testsuite/26_numerics/random/pr60037-neg.cc: Remove lineno so
that one dg-error matches both diagnostics.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Gaius Mulley [Wed, 17 Dec 2025 13:00:33 +0000 (13:00 +0000)]
PR modula2/123151: Unable to use IsNoError with Close in FIO library module
This is a bug fix to the library module FIO to allow Close to return a
boolean indicating success. Most probably in the future there should be
a GetStatus procedure provided and the FileStatus enumeration inside
FIO.mod should also be exported.
gcc/m2/ChangeLog:
PR modula2/123151
* gm2-libs/FIO.def (IsError): New procedure function.
(IsActive): Rewrite the comment.
(Exists): Ditto.
(OpenToRead): Ditto.
(OpenToWrite): Ditto.
(Close): Add an optional BOOLEAN return result.
* gm2-libs/FIO.mod (Close): Reimplement with an
optional BOOLEAN return result.
gcc/testsuite/ChangeLog:
PR modula2/123151
* gm2/pimlib/base/run/pass/FIO.mod: Reimplement.
Copy from gm2-libs/FIO.mod since FIO.def api has changed.
* gm2/pimlib/run/pass/testclose.mod: New test.
Rainer Orth [Wed, 17 Dec 2025 12:20:20 +0000 (13:20 +0100)]
testsuite: i386: Restrict gcc.target/i386/pr120881-1?.c to Linux
Two tests FAIL on Solaris x86:
FAIL: gcc.target/i386/pr120881-1a.c at line 4 (test for warnings, line )
FAIL: gcc.target/i386/pr120881-1b.c at line 4 (test for warnings, line )
producing no message contrary to what the tests expect. The reason is
similar to previous instances: Solaris doesn't support -mfentry. Like
previous cases, this patch thus restricts them to Linux.
Tested on i386-pc-solaris2.11 and x86_64-pc-linux-gnu.
Rainer Orth [Wed, 17 Dec 2025 12:17:32 +0000 (13:17 +0100)]
testsuite: c++: Skip g++.dg/cpp26/literals2.C on Solaris [PR112652]
The g++.dg/cpp26/literals2.C FAILs on Solaris like this:
FAIL: g++.dg/cpp26/literals2.C -std=gnu++11 (test for errors, line 10)
FAIL: g++.dg/cpp26/literals2.C -std=gnu++11 (test for errors, line 11)
FAIL: g++.dg/cpp26/literals2.C -std=gnu++11 (test for errors, line 13)
FAIL: g++.dg/cpp26/literals2.C -std=gnu++11 (test for errors, line 41)
FAIL: g++.dg/cpp26/literals2.C -std=gnu++11 (test for errors, line 42)
FAIL: g++.dg/cpp26/literals2.C -std=gnu++11 (test for errors, line 44)
As discussed in the PR, this is an issue with the Solaris iconv
implementation. While one could fix it by requiring GNU libiconv or
implement a workaround in libcpp, it seems easier to just skip the test
on Solaris. xfailing it isn't really an option since that would have to
be applied to every single affected dg-error which seems overkill.
Tested on i386-pc-solaris2.11 and x86_64-pc-linux-gnu.
benwu25 [Wed, 17 Dec 2025 11:59:05 +0000 (18:59 +0700)]
c++: clear in_declarator_p before parsing a lambda [PR121443]
We should set parser->in_declarator_p to false when parsing a lambda.
In this testcase, for example, a lambda in a function declarator
could contain a constructor, which would be disallowed in
cp_parser_decl_specifier_seq since in_declarator_p was true.
Nathaniel Shead [Sat, 13 Dec 2025 22:32:50 +0000 (09:32 +1100)]
c++: Don't record lambdas in concept evaluations [PR123075]
When evaluating a concept definition in a template, any lambdas in the
definition of the concept get instantiated in the context of where the
evaluation occurred.
This causes two issues:
- Any lambdas declared later in the body of the function get the wrong
discriminator, which causes ABI divergences with Clang.
- Modules streaming gets confused, because the lambda is keyed to an
unrelated declaration. Keying the lambda to the concept also doesn't
work because we'd really want to key it to a concept instantiation
(that doesn't exist) so that merging works correctly.
I think really we just want to throw away these lambdas declarations
after evaluating the concept. They can (and will) be recreated in
importers re-evaluating the concept with the given args regardless.
This patch implements this by disabling scope recording for an
instantiation of a lambda keyed to a concept, and pushing into an
unrelated context so that the lambda's type is not mistakenly added
into the scope it was instantiated from.
PR c++/123075
gcc/cp/ChangeLog:
* constraint.cc (evaluate_concept_check): Push to an unrelated
scope, but keep the same access context.
* pt.cc (tsubst_lambda_expr): Don't record lambda scopes for
lambdas attached to a concept.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-lambda25.C: New test.
* g++.dg/modules/lambda-13.h: New test.
* g++.dg/modules/lambda-13_a.H: New test.
* g++.dg/modules/lambda-13_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com> Reviewed-by: Patrick Palka <ppalka@redhat.com>
Tomasz Kamiński [Wed, 17 Dec 2025 09:32:54 +0000 (10:32 +0100)]
libstdc++: Make declaration and definition of generate_canonical consistent.
The r16-6177-g866bc8a9214b1d introduced type-constraint on _Urbg template
parameter in __glibcxx_concepts, with was inconsistent with declaration in
bits/random.h and definition in bits/random.tcc causing the missing symbol
errors in tests.
Furthermore, this made the mangled name of generate_canonical in C++20
mode different from older standard and previous versions of GCC.
libstdc++-v3/ChangeLog:
* include/bits/random.tcc (generate_canonical)
[!_GLIBCXX_USE_OLD_GENERATE_CANONICAL]: Use static_assert
instead of type-constraint on template parameter.
* testsuite/26_numerics/random/pr60037-neg.cc: Updated line
of error.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Tomasz Kamiński [Wed, 17 Dec 2025 09:32:54 +0000 (10:32 +0100)]
libstdc++: Fixed failing dg-error in random/pr60037-neg.cc tests.
libstdc++-v3/ChangeLog:
* include/bits/random.tcc (generate_canonical): Update
error message to match pre-existing one in random.h.
* testsuite/26_numerics/random/pr60037-neg.cc: Updated
line for error message.
Jakub Jelinek [Wed, 17 Dec 2025 08:16:46 +0000 (09:16 +0100)]
libstdc++: Fix up all_pedantic_errors.cc
On x86_64-linux I see
On x86_64-linux
FAIL: 17_intro/headers/c++1998/all_pedantic_errors.cc -std=gnu++17 (test for excess errors)
Excess errors:
/home/jakub/src/gcc/obj20/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/random.tcc:3681: error: ISO C++ does not support '__int128' for 'type name' [-Wpedantic]
/home/jakub/src/gcc/obj20/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/random.tcc:3698: error: ISO C++ does not support '__int128' for 'type name' [-Wpedantic]
This fixes it by adding __extension__.
2025-12-17 Jakub Jelinek <jakub@redhat.com>
* include/bits/random.tcc (std::generate_canonical): Use
__extension__ before __generate_canonical_{pow2,any} calls with
unsigned __int128 template arguments.
We have a few more template implementation files within the rust frontend
that use the hxx extension to make their content clear and highlight the
missing header guards.
* ast/rust-ast-collector.cc (TokenCollector::begin_describe_node):
Remove function.
(TokenCollector::end_describe_node): Likewise.
(TokenCollector::describe_node): Remove calls to begin/end.
* ast/rust-ast-collector.h: Specialize begin and end collect items. Add
more constructors to begin/end description.
* ast/rust-ast-dump.cc (Dump::Dump): Adapt to new configuration
options.
* ast/rust-ast-dump.h: Add new configuration options.
* rust-session-manager.cc (Session::dump_ast_pretty_internal): Use new
configuration options.
Rename the functions and split internal comments from node description.
gcc/rust/ChangeLog:
* ast/rust-ast-collector.cc (TokenCollector::comment): Use comment kind
(TokenCollector::begin_internal_comment): Rename from this...
(TokenCollector::begin_describe_node): ... to this.
(TokenCollector::end_internal_comment): Rename from this...
(TokenCollector::end_describe_node): ... to this.
(TokenCollector::internal_comment): Rename from this...
(TokenCollector::describe_node): ... to this.
(TokenCollector::visit): Change name in function calls.
(TokenCollector::visit_closure_common): Likewise.
(TokenCollector::visit_loop_common): Likewise.
* ast/rust-ast-collector.h: Adapt function prototypes, add a new
collect item kind for node description.
Benjamin Thos [Thu, 12 Dec 2024 13:51:53 +0000 (14:51 +0100)]
gccrs: Rework code to call one function when add comment
When we want to add an internal comment we know call one function that
wrap the code instead of calling two function, one at the beginning one
at the end.
gcc/rust/ChangeLog:
* ast/rust-ast-collector.cc (TokenCollector::internal_comment):
Wrapper function to add both comment.
(TokenCollector::visit): call of the wrapper function.
(TokenCollector::visit_closure_common): Same.
(TokenCollector::visit_loop_common): Same.
* ast/rust-ast-collector.h: Prototype of the wrapper function
Signed-off-by: Benjamin Thos <benjamin.thos@epita.fr>
Benjamin Thos [Tue, 22 Oct 2024 13:06:36 +0000 (13:06 +0000)]
gccrs: Add dump option to show node
Add a new dump option to show node node as
internal comment with a blacklist to ignore some
node.
gcc/rust/ChangeLog:
* ast/rust-ast-collector.cc (TokenCollector::begin_internal_comment):
Add internal comment to print node beginning.
(TokenCollector::end_internal_comment): Add internal comment to print
node end.
(TokenCollector::visit): Add the comments of the node visited.
(TokenCollector::visit_closure_common): Likewise.
(TokenCollector::visit_loop_common): Likewise.
* ast/rust-ast-collector.h: Add internal comment as a nes Kind.
* ast/rust-ast-dump.cc (Dump::Dump): add a Dump constructor to enable
internal.
* ast/rust-ast-dump.h: Add printing of internal comment in the dump
* rust-session-manager.cc (Session::enable_dump): Activate ast dump
and fill the blacklist.
(Session::handle_internal_blacklist): Parse the flag to get node to
be blacklisted.
(Session::compile_crate): Launch ast dump internal when asked.
(Session::dump_ast_pretty_internal): Call the visitor to dump
the internals.
* rust-session-manager.h (struct CompileOptions): add Interal in
Dump option enum.
Signed-off-by: Benjamin Thos <benjamin.thos@epita.fr>
Previously we aborted when querying the location on a MetaItemPathExpr,
the location should start on the path and continue over the expr but we
do not support that kind of location range yet.
gccrs: Use tl::expected in the parser to avoid error state
We made heavy use of error state within some AST node and it was the
source of multiple errors, and caused confusion with (null) pointers.
This commit removes some error state use within our parser in an attempt
to remove those error states later.
gcc/rust/ChangeLog:
* parse/rust-parse-impl.h (Parser::parse_inner_attributes): Change
return type to avoid empty/error values that may break invariants in
the AST.
(Parser::parse_inner_attribute): Likewise.
(Parser::parse_outer_attribute): Likewise.
(Parser::parse_outer_attributes): Likewise.
(Parser::parse_attribute_body): Likewise.
(Parser::parse_simple_path): Likewise.
(Parser::parse_macro_invocation): Likewise.
(Parser::parse_visibility): Likewise.
(Parser::parse_use_tree): Likewise.
(Parser::parse_delim_token_tree): Likewise.
(Parser::parse_identifier_or_keyword_token): Likewise.
(Parser::parse_token_tree): Likewise.
(Parser::parse_macro_rules_def): Likewise.
(Parser::parse_decl_macro_def): Likewise.
(Parser::parse_macro_invocation): Likewise.
(Parser::parse_macro_rule): Likewise.
(Parser::parse_macro_matcher): Likewise.
(Parser::parse_type_path_segment): Likewise.
(Parser::parse_path_expr_segment): Likewise.
(Parser::parse_type): Likewise.
(Parser::parse_type_no_bounds): Likewise.
(Parser::parse_items): Circumvent GCC 5 to 7 bug.
(is_simple_path_segment): Move to utility file.
(token_id_matches_delims): Likewise.
(is_likely_path_next): Remove unused function.
(Parser::parse_attr_input): Return a structure instead of a tuple.
* expand/rust-macro-builtins-offset-of.cc: Adapt call to expected.
* ast/rust-ast.cc (AttributeParser::parse_path_meta_item): Use empty
vector when an error is encountered.
* expand/rust-macro-builtins-include.cc: Likewise.
* parse/rust-parse.h: Update prototypes.
* parse/rust-parse-impl-proc-macro.cc: Likewise.
* ast/rust-ast.h: Remove error state from Visibility.
* ast/rust-item.h: Use private visibility instead of error.
* ast/rust-macro.h: Likewise.
* expand/rust-macro-expand.cc: Likewise.
* hir/rust-ast-lower.cc: Remove error case.
* rust-session-manager.cc: Use private visibility
* parse/rust-parse-utils.h: New file.
* parse/rust-parse-error.h: New file.
Tomasz Kamiński [Wed, 3 Dec 2025 13:06:59 +0000 (14:06 +0100)]
libstdc++: Provide conversion between atomic_ref of similar types.
This patch implements the P3860R1 (accepted as DR against C++20) and LWG4472.
The two constraints on the constructor (that T and U are similar types and
is_convertible_v<U*, T*>) are combined into a single check:
is_convertible_v<_Up(*)[1], _Tp(*)[1]>. While this check is not equivalent
for array of known bound to array of unknown bound conversions (T[N] to T[]),
this is irrelevant for atomic_ref, since instantiation with an array type is
ill-formed (due to the return type of load and other members).
The __atomic_ref_base constructor is modified to accept _Tp* instead of _Tp&.
This allows both the atomic_ref(atomic_ref<_Up> __other) and atomic_ref(_Tp& __t)
constructors to delegate to it. Furthermore, such approach does not require
dereferencing *__other._M_ptr, and thus avoid ADL-lookup for operator* and
issues related to it. The precondition check on alignment is moved specifically
to the atomic_ref(_Tp&) constructor, preventing redundant checks during atomic_ref
conversion.
A deleted atomic_ref(_Tp&&) constructor is introduced (per LWG4472).
This prevents the construction of atomic_ref<T> from atomic_ref<volatile T>
via the conversion operator.
libstdc++-v3/ChangeLog:
* include/bits/atomic_base.h
(__atomic_ref_base<const _Tp>::__atomic_ref_base): Accept
pointer instead of reference. Remove precondition check and
mark as noexcept.
(__atomic_ref_base<_Tp>::__atomic_ref_base): Accept pointer
insted of reference, and mark as noexcept.
* include/std/atomic (atomic_ref::atomic_ref(_Tp&)): Add
precondition check and take address of argument.
(atomic_ref::atomic_ref(_Tp&&)): Define as deleted.
(atomic_ref::atomic_ref(atomic_ref<_Up>)): Define.
* include/bits/shared_ptr_atomic.h (_Sp_atomic::_Atomic_count):
Pass address to __atomic_ref constructor.
* include/std/barrier (__tree_barrier_base::_M_arrive)
(__tree_barrier::arrive): Pass address to __atomic_ref constructor.
* testsuite/29_atomics/atomic_ref/ctor.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jonathan Wakely [Wed, 10 Dec 2025 14:26:17 +0000 (14:26 +0000)]
libstdc++: Optimize compilation time for signed/unsigned integer traits
Replace the O(n) definitions using __is_one_of with constant-time
checks that look for a static member in the __is_integral_helper class
template. That class template is already specialized for every signed
and unsigned integer type, so we don't need to define any additional
specializations. We can just add a static data member that says whether
the type is a signed integer type, an unsigned integer type, or neither.
The __is_signed_integer and __is_unsigned_integer traits can then
inspect that value.
The new enum type could be extended in future to distinguish the
character types (char, wchar_t, char8_t, char16_t, and char32_t) and
bool from non-integer types, but that isn't needed for now.
libstdc++-v3/ChangeLog:
* include/std/type_traits (_Integer_kind): New enum type.
(__is_integral_helper::_S_kind): New static data member in
primary template and each explicit specialization.
(__is_signed_integer, __is_unsigned_integer): Use _S_kind
instead of O(n) disjunction with is_same.
Reviewed-by: Patrick Palka <ppalka@redhat.com> Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jonathan Wakely [Tue, 2 Dec 2025 15:26:31 +0000 (15:26 +0000)]
libstdc++: Do not optimize std::copy to memcpy for bool output [PR122907]
Copying narrow characters to a range of bool using std::copy cannot be
optimized to use std::memcpy. Assignment of an arbitrary integer to a
bool needs to convert all non-zero values to true, so is not a simple
memcpy-like or bit_cast-like operation. We currently get this wrong and
optimize it to memcpy, producing invalid bool values.
By making __memcpyable_integer<bool> false we disable memcpy
optimizations for heterogeneous std::copy and std::move calls where
either the source or destination type is bool. Copies where both types
are bool can still optimize to memcpy, because we don't check
__memcpyable_integer in that case.
This disables the memcpy optimization for bool as the source type,
which isn't actually necessary (the representation of bool in GCC is
0x00 or 0x01 and so copying bool to char is just a bit_cast). We don't
currently have a straightforward way to allow memcpy for bool to char
but disallow the inverse. This seems acceptable as using std::copy with
bool inputs and narrow character outputs is probably not common enough
for this to be an important optimization to do in the library code.
libstdc++-v3/ChangeLog:
PR libstdc++/122907
* include/bits/cpp_type_traits.h (__memcpyable_integer<bool>):
Define as false.
* testsuite/25_algorithms/copy/122907.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Patrick Palka <ppalka@redhat.com>
Jose E. Marchesi [Tue, 16 Dec 2025 21:50:15 +0000 (22:50 +0100)]
a68: fix modules testsuite to not include flags in test name [PR algol68/123131]
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/testsuite/ChangeLog
PR algol68/123131
* algol68/compile/modules/compile.exp: Pass module include path
via extra_flags to algol68-dg-runtest.
* algol68/execute/modules/execute.exp: Pass module include path
via algol68_compile_args.
* lib/algol68-dg.exp (MODULES_OPTIONS): Delete.
(algol68-dg-runtest): Do not use MODULE_OPTIONS.
* lib/algol68-torture.exp (BUILT_MODULES_DIR): Delete.
(algol68-torture-execute): Do not use BUILT_MODULES_DIR.
Nathan Myers [Thu, 7 Aug 2025 02:38:44 +0000 (22:38 -0400)]
libstdc++: New generate_canonical impl (P0952, LWG2524) [PR119739]
Implement P0952R2 "A new specification for
std::generate_canonical", fixing issue LWG 2524.
It has us start over, using new entropy, if the naïve generation
of a value in [0..1) comes up equal to 1.0, which occurs too
rarely for the change to measurably affect performance, but
does affect the number of calls to the underlying random bit
generator.
The old implementation is preserved, guarded by preprocessor
macro _GLIBCXX_USE_OLD_GENERATE_CANONICAL, for use where behavior
exactly matching previous runs is required.
The fix is extended to all of C++11 to 26. The public function
dispatches to variations optimized for requested bit depth `d`,
using minimal integer sizes for exact intermediate calculations.
It is faster than the old implementation, which computed a
floating-point logarithm, and performs all intermediate
calculations on integer types. It does not allow the IEEE half-
precision type `float16_t`, as its range is not large enough to
represent intermediate integer values specified, but does allow
`bfloat16_t`.
This implementation varies from the Standard in retaining in the
output mantissa as much as possible of the entropy obtained from
the provided random bit generator, not just the leading `d` bits
of randomness as specified, and in permitting use on floating
point types beyond float, double, and long double. The macro
_GLIBCXX_GENERATE_CANONICAL_STRICT may be defined to obtain the
exact Standard behavior.
This patch also adds tests for statistical properties, and adds
new static asserts on template argument requirements where
supported. It adds tests using non-optimal RNGs that yield
values 0..999999 and 0..0x7ffffffe.
A test for the case addressed in LWG 2524 already appeared in
64351.cc. This change amounts to a different resolution for
bugzilla PR64351 and LWG 2524.
libstdc++-v3/ChangeLog:
PR libstdc++/119739
* include/bits/random.tcc: Add generate_canonical impl for C++26.
* testsuite/26_numerics/random/uniform_real_distribution/operators/64351.cc:
Adapt test for both pre- and post- C++26.
* testsuite/26_numerics/random/uniform_real_distribution/operators/gencanon.cc:
Test for float and double from 32-bit RNG, including 1.0 do-over.
Jose E. Marchesi [Tue, 16 Dec 2025 17:17:37 +0000 (18:17 +0100)]
a68: support only one definition module per prelude packet
At this point we only support having a single definition module in
each prelude packet. It is planned to change this, and also to
support local not-toplevel modules, but not in the next GCC release.
So until that gets fully implemented, it is pointless to support
parsing multiple contracted module definitions.
This commit removes this support from the parser and adjusts several
tests that were making use of it.
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog
* a68-parser-bottom-up.cc (reduce_prelude_packet): Do not support
multiple module definitions per packet.
gcc/testsuite/ChangeLog
* algol68/compile/error-compile-unknown-tag-1.a68: Use a single
module per packet.
* algol68/compile/error-module-coercions-1.a68: Likewise.
* algol68/compile/error-module-ranges-1.a68: Likewise.
* algol68/compile/module-2.a68: Likewise.
* algol68/compile/module-pub-mangling-1.a68: Likewise.
* algol68/compile/module-pub-mangling-2.a68: Likewise.
* algol68/compile/module-pub-mangling-3.a68: Likewise.
* algol68/compile/module-pub-mangling-4.a68: Likewise.
* algol68/compile/module-pub-mangling-5.a68: Likewise.
* algol68/compile/module-pub-mangling-6.a68: Likewise.
* algol68/compile/warning-module-hidding-1.a68: Likewise.
David Malcolm [Tue, 16 Dec 2025 17:10:26 +0000 (12:10 -0500)]
analyzer: fix state dumps for return_event [PR122003]
In the reimplementation of supergraph (r16-6063-g0b786d961d4426) the
class return_event moved from being a subclass of superedge_event to
a subclass of checker_event, thus using checker_event::get_program_state
which returns null.
This stopped e.g. HTML state-graph output showing state at return events
in e.g. event (8) of
https://dmalcolm.fedorapeople.org/gcc/2025-12-15/state-diagram-1.c.html
Fixed by implementing return_event::get_program_state.
Patrick Palka [Tue, 16 Dec 2025 16:22:58 +0000 (11:22 -0500)]
libstdc++: Implement P2408R5 C++20 iterators as inputs to STL algos
From the paper's abstract:
Change the iterator requirements for non-Ranges algorithms. For
forward iterators and above that are constant iterators, instead of
requiring that iterators meet certain Cpp17...Iterator requirements,
require that the iterators model certain iterator concepts. This makes
iterators from several standard views usable with non-Ranges
algorithms that require forward iterators or above, such as the
parallel overloads of most algorithms.
This patch narrowly implements P2408R5 in C++23 mode and C++20 mode
(as an extension). "Narrowly" because just as in the paper, we don't
attempt to relax the requirements of mutable iterators even though it's
possible in theory. Note that the PSTL algorithm requirements have
already been relaxed in r15-3650. And we don't bother touching the
deprecated parallel mode algorithms under ./include/parallel.
The main workhorse of this paper is a new helper
__iterator_concept_or_category that replaces eligible uses of
__iterator_category and iterator_traits::iterator_category. This new
helper considers both the iterator_concept and iterator_category of the
given iterator and returns the former if it's at least as strong as the
latter. It's implemented in terms of the __promotable_iterator concept
added in r16-2588 that made std::advance etc aware of C++20 iterators.
Note that this helper doesn't check the actual C++20 iterator concepts
(which check syntactic requirements along with iterator_concept if it's
defined) and instead just checks for, and fully trusts, the
iterator_concept defined by the iterator type. This is a slight
deviation from the paper but IMHO it's consistent with the existing
trusting of iterator_category and should be good enough in practice,
though it means C++20 iterators that don't define iterator_concept will
not be recognized as such by this helper even if they otherwise model
the std::foo_iterator concept. (An undefined iterator_concept
effectively defaults to random_access_iterator_tag.)
Most of the changes made here are effectively optimizations that don't
have a semantic impact, e.g. for std::reduce. I added tests for a
couple of algorithms where these changes are observable.
The new __iterator_concept_or_category helper can probably also be used
to fix PR100070 "Standard library container iterator-pair constructors
should check C++20 iterator concepts".
As a follow-up to this patch we should either remove the Boost-style
concept checks, or relax them accordingly. It seems we're leaning
towards removing them outright; see this thread:
https://gcc.gnu.org/pipermail/libstdc++/2025-May/061568.html
As suggested by Tomasz, this patch also introduces a _GLIBCXX_ITER_MOVE
wrapper around ranges::iter_move that also converts to the iterator's
value type (and is usable before C++20 as well).
PR libstdc++/113299
libstdc++-v3/ChangeLog:
* include/bits/deque.tcc (__copy_move_a1): Constrain with
__is_any_random_access_iter instead of __is_random_access_iter.
(__copy_move_backward_a1): Likewise.
(__equal_aux1): Likewise.
* include/bits/stl_algo.h (__search_n): Use
__iter_concept_or_category instead of __iterator_category
or iterator_traits::iterator_category.
(find_end): Likewise.
(__is_permutation): Likewise.
(for_each_n): Likewise.
(unique_copy): Likewise, for constant iterators.
(sample): Likewise, for constant iterators.
* include/bits/stl_algobase.h (__copy_move_a1): Adjust
deque-based forward declaration accordingly.
(__copy_move_backward_a1): Likewise.
(__equal_aux1): Likewise.
(__lexicographical_compare_impl): Use
__iter_concept_or_category instead of __iterator_category or
iterator_traits::iterator_category.
(__equal4): Likewise.
* include/bits/stl_iterator_base_funcs.h
(__iter_concept_or_category): New.
(__is_any_random_access_iter): New.
(_GLIBCXX_ITER_MOVE): New.
* include/bits/stl_uninitialized.h (uninitialized_copy_n):
Use __iterator_concept_or_category instead of
__iterator_category for the constant iterator __first.
(__uninitialized_copy_n_pair): Likewise.
* include/bits/version.def (algorithm_iterator_requirements):
Define.
* include/bits/version.h: Regenerate.
* include/std/algorithm: Provide the FTM
__cpp_lib_algorithm_iterator_requirements.
* include/std/memory: Likewise.
* include/std/numeric: Likewise. Include
<bits/stl_iterator_base_funcs.h>.
(reduce): Use __is_any_random_access_iter instead of
__is_random_access_iter.
(transform_reduce): Likewise.
(inclusive_scan): Use _GLIBCXX_ITER_MOVE instead of std::move.
* testsuite/25_algorithms/find_end/c++20_iter.cc: New test.
* testsuite/25_algorithms/sample/c++20_iter.cc: New test.
* testsuite/25_algorithms/search_n/c++20_iter.cc: New test.
* testsuite/25_algorithms/unique_copy/c++20_iter.cc: New test.
* testsuite/26_numerics/inclusive_scan/c++20_iter.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Iain Sandoe [Sun, 14 Dec 2025 11:24:40 +0000 (11:24 +0000)]
aarch64: Make the test for available cached PCS data more robust.
When we are emitting MI thunks, it can be the case that the
target function of the thunk has already been compiled, and
considered complete, with at least part of the relevant data
freed.
The deal with this, we amend the test for the availability
of the cached PCS value to check for the presence of both the
cfun and the machine content.
Since these functions are in a hot code path, use
gcc_checking_assert().
gcc/ChangeLog:
* config/aarch64/aarch64.cc
(aarch64_function_abi): Use checking assert.
(aarch64_fndecl_abi): Test for the availability of the
machine content before trying to look up the cached PCS.
Use a checking assert.
These options are used in order to specify a mapping from module
indicants to file basenames. The compiler will base its search for
the modules on these basenames rather on the default schema of
deriving the basename from the module indicant.
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog
* lang.opt (-fmodules-map): New option.
(-fmodules-map-file): Likewise.
* a68.h: Add prototype for a68_process_module_map.
* a68-imports.cc (SKIP_WHITESPACES): Define.
(PARSE_BASENAME): Likewise.
(PARSE_INDICANT): Likewise.
(a68_process_module_map): New function.
* a68-lang.cc: (a68_init): Move initialization of
A68_MODULE_FILES from there...
(a68_init_options): to here.
(a68_handle_option): Handle OPT_fmodules_map and
OPT_fmodules_map_.
* a68-parser-pragmat.cc (handle_access_in_pragmat): Normalize
module indicants to upper case.
* ga68.texi (Module search options): New section.
Jose E. Marchesi [Mon, 15 Dec 2025 13:03:01 +0000 (14:03 +0100)]
a68: introduce a68_file_size and a68_file_read
This commit introduces two new utility functions that replace some
ad-hoc infrastructure in the scanner.
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog
* a68.h: Prototypes for a68_get_file_size and a68_file_read.
* a68-parser-scanner.cc (a68_file_size): New function.
(a68_file_read): Renamed from io_read.
(get_source_size): Deleted function.
(include_files): Use a68_file_size and a68_file_read.
In the expansion of cstoresi4 insn patterns, LT[U] comparisons where the
second operand is an integer constant are canonicalized to LE[U] ones with
one less than the original.
/* example */
int test0(int a) {
return a < 100;
}
unsigned int test1(unsigned int a) {
return a <= 100u;
}
void test2(int a[], int b) {
int i;
for (i = 0; i < 16; ++i)
a[i] = (a[i] <= b);
}
This patch reverts such canonicalization by adding 1 to the comparison value
and then converting it back from LE[U] to LT[U], which better matches the
output machine instructions. This patch also makes it easier to benefit
from other optimizations such as CSE, constant propagation, or loop-invariant
hoisting by XORing the result with a register that has a value of 1, rather
than subtracting 1 and then negating the sign to invert the truth of the
result.
* config/xtensa/xtensa.cc (xtensa_expand_scc_SALT):
New sub-function that emits the SALT/SALTU instructions.
(xtensa_expand_scc): Change the part related to the SALT/SALTU
instructions to a call to the above sub-function.
xtensa: Remove variables only used to pass the return of end_sequence()
As a result of the automatic replacement by commit 4dd13988c93c24ba3605f4b9cafc97515c34f2ac,
there are several code fragments that receive the return value of
end_sequence() and immediately use it as the return value of the function
itself.
It is clear that in such cases, it would be more natural to pass the return
value of end_sequence() directly to the return statement without passing it
through a variable.
Applying this patch naturally does not change any functionality.
gcc/ChangeLog:
* config/xtensa/xtensa.cc
(xtensa_expand_block_set_libcall,
xtensa_expand_block_set_unrolled_loop,
xtensa_expand_block_set_small_loop, xtensa_call_tls_desc):
Change the return statement to pass the return value of
end_sequence() directly without going through a variable, and
remove the definition of that variable.
Richard Biener [Tue, 16 Dec 2025 12:08:19 +0000 (13:08 +0100)]
testsuite/123137 - fix FAIL of g++.dg/vect/pr64410.cc on i?86
The following works around SRA not being able to decompose an
aggregate copy of std::complex because with x87 math ld/st pairs
are not bit-preserving by adding -msse -mfpmath=sse. This avoids
spurious failures of the testcase.
PR testsuite/123137
* g++.dg/vect/pr64410.cc: Add -mfpmath=sse -msse on x86.
projects / thirdparty / gcc.git / log
