Jonathan Wakely [Thu, 18 Dec 2025 16:39:46 +0000 (16:39 +0000)]
libstdc++: Fix chrono::parse to read from wide strings [PR123147]
When we extract wide characters and insert them into a stringstream to
be parsed as a floating-point value, we should use a stringstream of
char, not wchar_t.
libstdc++-v3/ChangeLog:
PR libstdc++/123147
* include/bits/chrono_io.h (_Parser::operator()) <%S>: Use a
buffer of narrow characters to be parsed by std::from_chars.
* testsuite/std/time/parse/parse.cc: Check wchar_t parsing.
Tomasz Kamiński [Fri, 19 Dec 2025 12:07:00 +0000 (13:07 +0100)]
libstdc++: Make more _Safe_iterator functions in constexpr in C++20.
This functions are indirectly called from flat_ containers operations
(from preconditions check of lower_bound, upper_bound, ...) that were
made constexpr by r16-6026-gbf9dd44a97400e, leading to test with
in _GLIBCXX_DEBUG mode.
For __can_advance we uncoditionally return true in constant evaluation,
similary to __valid_range. The constexpr iterator will detect comparision
of iterator to different ranges.
libstdc++-v3/ChangeLog:
* include/debug/helper_functions.h (__gnu_debug::__can_advance):
Declare as _GLIBCXX20_CONSTEXPR.
* include/debug/safe_iterator.h (__gnu_debug::__can_advance):
Define as _GLIBCXX20_CONSTEXPR, and return true for constexpr
evaluation.
(__gnu_debug::__base): Define as _GLIBCXX20_CONSTEXPR.
Jason Merrill [Fri, 19 Dec 2025 08:20:13 +0000 (15:20 +0700)]
c++: lambda template arg in abbreviated template [PR117034]
A lambda used as a non-type template argument to a type-constraint in the
first parameter of an abbreviated function template was wrapped in a
TARGET_EXPR because we hadn't opened the implicit template scope yet. After
r16-5115 changed convert_template_argument to call
instantiate_non_dependent_expr_internal on non-dependent expressions, these
TARGET_EXPRs began hitting the default case in tsubst_expr, causing an ICE.
So let's enter implicit template scope as soon as we see the concept-name;
at that point we know we're declaring an abbreviated template.
PR c++/117034
gcc/cp/ChangeLog:
* parser.cc (maybe_start_implicit_template): Split out from...
(synthesize_implicit_template_parm): ...here.
(cp_parser_template_id): Call it.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-template-pr117034.C: New test.
Egas Ribeiro [Thu, 11 Dec 2025 13:30:49 +0000 (13:30 +0000)]
c++: Fix ICE with functional cast to reference in template [PR123044]
When processing a functional cast to a reference type in a template
context, build_functional_cast_1 wasn't calling convert_from_reference.
This left the expression with a reference type, which later triggered
an assertion in implicit_conversion from r15-6709 that expects
expression types to already be dereferenced.
In contrast, cp_build_c_cast already calls convert_from_reference on
the result in template contexts, so C-style casts like (R)x worked
correctly.
The fix makes functional casts consistent with C-style casts by
calling convert_from_reference before returning in the template
processing path.
PR c++/123044
gcc/cp/ChangeLog:
* typeck2.cc (build_functional_cast_1): Call convert_from_reference
on template CAST_EXPR to match C-style cast behavior.
gcc/testsuite/ChangeLog:
* g++.dg/template/implicit-func-cast.C: New test.
Signed-off-by: Egas Ribeiro <egas.g.ribeiro@tecnico.ulisboa.pt> Reviewed-by: Jason Merrill <jason@redhat.com>
Egas Ribeiro [Sat, 13 Dec 2025 20:06:09 +0000 (20:06 +0000)]
c++: Fix injected-class-name lookup with multiple bases [PR122509]
When looking up an unqualified injected-class-name in a member access
expression (e.g., D().v<int>), cp_parser_lookup_name calls lookup_member
with protect=0, causing it to return NULL on ambiguity instead of the
candidate list. This prevented the existing DR 176 logic in
maybe_get_template_decl_from_type_decl from resolving the ambiguity.
Per DR 176, if all ambiguous candidates are instantiations of the same
class template and the name is followed by a template-argument-list,
the reference is to the template itself and is not ambiguous.
Fix by using protect=2 to return the ambiguous candidate list.
PR c++/122509
gcc/cp/ChangeLog:
* parser.cc (cp_parser_lookup_name): Use protect=2 instead of
protect=0 when calling lookup_member.
gcc/testsuite/ChangeLog:
* g++.dg/tc1/dr176-2.C: New test.
Signed-off-by: Egas Ribeiro <egas.g.ribeiro@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Tobias Burnus [Fri, 19 Dec 2025 11:07:58 +0000 (12:07 +0100)]
OpenMP: uses_allocators with ';'-separated list
OpenMP 6.0 has the following wording for the uses_allocators clause:
"More than one clause-argument-specification may be specified";
this permits ';' lists. While that's pointless for predefined
allocators, for user-defined allocators it saves redundant
') uses_allocators(' by permitting:
uses_allocators( traits(t1): alloc1 ; traits(t2): alloc2 )
Additionally, the order in the tree dump has been changed to
place the modifiers before the allocator variable, matching
the input syntax.
gcc/c/ChangeLog:
* c-parser.cc (c_parser_omp_clause_uses_allocators): Accept
multiple clause-argument-specifications separated by ';'.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_omp_clause_uses_allocators): Accept
multiple clause-argument-specifications separated by ';'.
gcc/fortran/ChangeLog:
* openmp.cc (gfc_match_omp_clause_uses_allocators): Accept
multiple clause-argument-specifications separated by ';'.
gcc/ChangeLog:
* tree-pretty-print.cc (dump_omp_clause): For uses_allocators,
print modifier before allocator variable.
xtensa: Make the definition of xtensa_cstoresi_operator more appropriate
The description of 'cstoremode4' in gccint says:
"These operations may FAIL, but should do so only in relatively uncommon
cases; if they would FAIL for common cases involving integer comparisons,
it is best to restrict the predicates to not allow these operands."
-- 16.10 Standard Pattern Names For Generation, gccint (the latest)
Therefore, it is preferable to include unsigned comparisons in the operator
constraints of the pattern only if the machine instructions emitted by the
pattern require such comparisons.
gcc/ChangeLog:
* config/xtensa/predicates.md (xtensa_cstoresi_operator):
Change it to include unsigned comparisons only when TARGET_SALT is
enabled.
Jakub Jelinek [Fri, 19 Dec 2025 10:24:02 +0000 (11:24 +0100)]
c++: Fix stabilization of bitfields [PR122772]
The following testcase is rejected, because due to the C++17
b @= a ordering of side-effects cp_stabilize_reference is called
on the lhs of the compound assignment. For some cases
cp_stabilize_reference just uses stabilize_reference, but for other
cases it attempts to bind a reference to the expression.
This doesn't work for bit-fields and DECL_PACKED fields though,
we can't take address of a bit-field (nor DECL_PACKED field)
and error on that.
This patch introduces for this another wrapper around
stabilize_reference, which for clk_bitfield | clk_packed handles
some trees stabilize_reference doesn't handle correctly for C++,
and for the rest defers to stabilize_reference.
This way, we can introduce multiple SAVE_EXPRs (like stabilize_expr
itself already can as well), but can handle even the weirdest
lhs expressions for which lvalue_kind returns clk_bitfield or clk_packed
set.
2025-12-19 Jakub Jelinek <jakub@redhat.com>
PR c++/122772
* tree.cc (cp_stabilize_bitfield_reference): New function.
(cp_stabilize_reference): Use it for stabilization of
clk_bitfield or clk_packed lvalues.
Jakub Jelinek [Fri, 19 Dec 2025 10:12:21 +0000 (11:12 +0100)]
c++, dwarf2out: Debug info for namespace scope structured bindings [PR122968]
As the following testcase shows, we weren't emitting any debug info for
namespace scope structured bindings (except for tuple based ones, those
worked fine).
There are multiple problems:
1) for tuple based structured bindings there is cp_finish_decl and the
VAR_DECLs are registered in varpool, but the other ones are just
VAR_DECLs with DECL_VALUE_EXPR for elements of the underlying VAR_DECL,
so they don't really appear in the IL; and we weren't calling
early_global_decl debug hook on those
2) fixing that makes those appear only with -fno-eliminate-unused-symbols,
because whether something is used is determined by the presence of
varpool node for it; I think varpool is unprepared to handle
DECL_VALUE_EXPR VAR_DECLs, those would appear always unused;
so, the patch instead adds mapping from the underlying VAR_DECL
to the structured bindings needed for debug info in an artificial
attribute and when marking the underlying VAR_DECL of a structured
binding as used, it marks all the structured bindings attached to it
as well
3) with this, the DW_TAG_variable DIEs for structured bindings appear even
without -fno-eliminate-unused-symbols, but they still don't have
locations; for that we need to arrange when we add DW_AT_location to the
underlying variable to also add DW_AT_location to the structured bindings
afterwards
Note, this patch doesn't improve the structured bindings bound to bitfields
case the PR was filed for originally, neither at namespace scope nor at
block scope. That will need to be handled incrementally.
2025-12-19 Jakub Jelinek <jakub@redhat.com>
PR debug/122968
gcc/
* dwarf2out.cc (premark_used_variables): Handle "structured bindings"
attribute.
(dwarf2out_late_global_decl): Likewise.
gcc/cp/
* decl.cc (cp_finish_decomp): For structured bindings at namespace
scope which have DECL_HAS_VALUE_EXPR_P set, call early_global_decl
debug hook and put all such structured bindings into
"structured bindings" attribute arguments on the underlying decl.
gcc/testsuite/
* g++.dg/guality/decomp1.C: New test.
Jakub Jelinek [Fri, 19 Dec 2025 10:04:50 +0000 (11:04 +0100)]
++: Fix up cp_compare_floating_point_conversion_ranks for dfp [PR122834]
The following testcase ICEs in cp_compare_floating_point_conversion_ranks,
when it is called on one extended floating point type (right now always
a binary floating point type) and a decimal floating point type (which
we currently handle as neither standard nor extended floating point type,
similarly to e.g. __float128 and similar types).
There is an assertion that fails in that case.
When no extended floating point types are involved, e.g. common type
choice is quite arbitrary if TYPE_PRECISION is the same, e.g.
auto a = 0.0DL + 1.0Q;
auto b = 1.0Q + 0.0DL;
chooses the first type in both cases, so decltype (0.0DL) in the first
case and __float128 in the second case.
Now, when one type is extended floating point, I think we should follow
the C++23 rules, which say that conversion ranks are unordered if the
set of the values of both types are neither proper subsets nor supersets
of the other, which is I think the case of binary vs. decimal,
e.g. 0.3D{F,D,L} is not exactly representable in any binary floating point
format and I thought e.g. (1.0FNN + __FLTNN_EPSILON__) * __FLTNN_MIN__
is not representable in any decimal floating point. At least, for
_Float32, it needs 112 decimal digits to represent it exactly
0.00000000000000000000000000000000000001175494490952133940450443629595204006810278684798281709160328881985245648433835441437622648663818836212158203125
and _Decimal128 has only 34 significant digits, for _Float64
that is already 767 significant digits etc.
Though, _Float16 is a different case.
The following helper program:
int
main ()
{
char buf[256], *p, *q;
size_t l, ml = 0;
{
union { _Float16 x; unsigned short y; } u, v;
for (int i = 0; i < 0x7c00; ++i)
{
u.y = i;
_Float32 x = u.x;
strfromf32 (buf, 255, "%.254f", x);
for (p = buf; *p == '0' || *p == '.'; ++p)
;
if (*p == '\0')
continue;
for (q = strchr (p, '\0') - 1; *q == '0' || *q == '.'; --q)
;
q[1] = '\0';
l = strlen (p);
if (strchr (p, '.'))
--l;
if (ml < l)
ml = l;
}
}
printf ("%zd\n", ml);
ml = 0;
{
union { __bf16 x; unsigned short y; } u, v;
for (int i = 0; i < 0x7f80; ++i)
{
u.y = i;
_Float32 x = u.x;
strfromf32 (buf, 255, "%.254f", x);
for (p = buf; *p == '0' || *p == '.'; ++p)
;
if (*p == '\0')
continue;
for (q = strchr (p, '\0') - 1; *q == '0' || *q == '.'; --q)
;
q[1] = '\0';
l = strlen (p);
if (strchr (p, '.'))
--l;
if (ml < l)
ml = l;
}
}
printf ("%zd\n", ml);
}
prints
21
96
As _Decimal32 has 7 and _Decimal64 16 decimal digits, I think neither
_Float16 nor decltype (0.0bf16) is proper subset of values of those types,
but as _Decimal128 has 34 decimal digits, I'd say _Float16 is a proper
subset of _Decimal128 while decltype (0.0bf16) is not.
Example of the 21 decimal digits for _Float16 is
0x1.a3cp-14f16 (0x68f u.y), which is exactly 0.000100076198577880859375
2025-12-18 Jakub Jelinek <jakub@redhat.com>
PR c++/122834
* typeck.cc (cp_compare_floating_point_conversion_ranks): Return
3 if fmt2->b is 10 except for _Float16 vs. _Decimal128, in that
case return -2.
* g++.dg/dfp/pr122834-1.C: New test.
* g++.dg/dfp/pr122834-2.C: New test.
Jakub Jelinek [Fri, 19 Dec 2025 09:13:45 +0000 (10:13 +0100)]
c++: Reject array new with -fexceptions with deleted dtor [PR123030]
For array new and -fexceptions, we only try to build cleanup if
TYPE_HAS_NONTRIVIAL_DESTRUCTOR and so don't complain if the
array element has trivial but deleted destructor.
The following patch changes it to build the dtor whenever
type_build_dtor_call but only registers it as cleanup if the cleanup
has TREE_SIDE_EFFECTS. build_vec_delete_1 has a special
case for these type_build_dtor_call && !TYPE_HAS_NONTRIVIAL_DESTRUCTOR
cases where it does less work.
Though, I wonder if we also shouldn't test whether the ctor isn't noexcept,
then we wouldn't have to change the new4.C test. Though, clang++ rejects
that as well even when it has noexcept ctor.
2025-12-19 Jakub Jelinek <jakub@redhat.com>
PR c++/123030
* init.cc (build_vec_init): Call build_vec_delete_1 for -fexceptions
even if just type_build_dtor_call, not only when
TYPE_HAS_NONTRIVIAL_DESTRUCTOR. But register cleanups only
for TYPE_HAS_NONTRIVIAL_DESTRUCTOR.
* g++.dg/cpp0x/deleted18.C: New test.
* g++.dg/cpp0x/new4.C: Expect an error.
Jakub Jelinek [Fri, 19 Dec 2025 09:12:06 +0000 (10:12 +0100)]
c++: Fix up expansion statement handling
I've noticed that in many spots of the expansion statement handling I've
handled incorrectly the creation of VAR_DECLs which are constexpr
in the spec (or can be constexpr when user writes it that way).
All I've done was set DECL_DECLARED_CONSTEXPR_P and TREE_READONLY
flags on the VAR_DECL, but haven't made sure the TREE_TYPE is const
qualified as well (with the exception of references obviously).
Haven't touched spots which are always references, e.g. when it is
constexpr auto &&var etc.
Fixing this revealed some problems:
1) one fixed by first hunk in pt.cc, where the i variable was created
with get_target_expr and thus now is const as well and so operator++
on it doesn't work; used build_target_expr_with_type to make it
non-const
2) several tests got it wrong and didn't actually support calling
operator *, operator != and operator + on const objects; fixed by
making those operators const qualified.
2025-12-19 Jakub Jelinek <jakub@redhat.com>
* parser.cc (cp_build_range_for_decls): If expansion_stmt_p,
where we are setting DECL_DECLARED_CONSTEXPR_P on begin/end, use
const qualified iter_type.
* pt.cc (finish_expansion_stmt): Use build_target_expr_with_type
with cv_unqualified to create it instead of get_target_expr to
make it non-const qualified. When creating VAR_DECLs with
DECL_DECLARED_CONSTEXPR_P, make sure they have const qualified
type unless they are references.
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.
projects / thirdparty / gcc.git / log
