| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Since r12-5426 apply_late_template_attributes suppresses various global
state to avoid applying active pragmas to earlier declarations; we also
need to override target_option_current_node.
PR c++/114772
PR c++/101180
gcc/cp/ChangeLog:
* pt.cc (apply_late_template_attributes): Also override
target_option_current_node.
gcc/testsuite/ChangeLog:
* g++.dg/ext/pragma-target2.C: New test.
|
|
Here when merging the two decls, remove_contract_attributes loses
ATTR_IS_DEPENDENT on the format attribute, so apply_late_template_attributes
just returns, so the attribute doesn't get propagated to the type where the
warning looks for it.
Fixed by using copy_node instead of tree_cons to preserve flags.
PR c++/116954
gcc/cp/ChangeLog:
* contracts.cc (remove_contract_attributes): Preserve flags
on the attribute list.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wformat-3.C: New test.
|
|
|
|
Currently, pruned lambda captures are still leftover in the function's
BLOCK and topmost BIND_EXPR; this doesn't cause any issues for normal
compilation, but does break modules streaming as we try to reconstruct a
FIELD_DECL that no longer exists on the type itself.
PR c++/119755
gcc/cp/ChangeLog:
* lambda.cc (prune_lambda_captures): Remove pruned capture from
function's BLOCK_VARS and BIND_EXPR_VARS.
gcc/testsuite/ChangeLog:
* g++.dg/modules/lambda-10_a.H: New test.
* g++.dg/modules/lambda-10_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
On Darwin and other targets with !can_alias_cdtor, we instead go to
maybe_thunk_ctor, which builds a thunk function that calls the general
constructor. And then cp_fold tries to constant-evaluate that call, and we
ICE because we don't expect to ever be asked to constant-evaluate a call to
a trivial function.
No new test because this fixes g++.dg/torture/tail-padding1.C on affected
targets.
PR c++/111075
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_call_expression): Allow trivial
call from a thunk.
|
|
When remapping existing specializations of a hidden template friend from
a previous declaration to the new definition, we must remap only those
specializations that match this new definition, but currently we
remap all specializations (since they all appear in the same
DECL_TEMPLATE_INSTANTIATIONS list of the most general template).
Concretely, in the first testcase below, we form two specializations of
the friend A::f, one with arguments {{0},{bool}} and another with
arguments {{1},{bool}}. Later when instantiating B, we need to remap
these specializations. During the B<0> instantiation we only want to
remap the first specialization, and during the B<1> instantiation only
the second specialization, but currently we remap both specializations
twice.
tsubst_friend_function needs to determine if an existing specialization
matches the shape of the new definition, which is tricky in general,
e.g. if the outer template parameters may not match up. Fortunately we
don't have to reinvent the wheel here since is_specialization_of_friend
seems to do exactly what we need. We can check this unconditionally,
but I think it's only necessary when dealing with specializations formed
from a class template scope previous declaration, hence the
TMPL_ARGS_HAVE_MULTIPLE_LEVELS check.
PR c++/119807
PR c++/112288
gcc/cp/ChangeLog:
* pt.cc (tsubst_friend_function): Skip remapping an
existing specialization if it doesn't match the shape of
the new friend definition.
gcc/testsuite/ChangeLog:
* g++.dg/template/friend86.C: New test.
* g++.dg/template/friend87.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
Since std::vector became usable in constant evaluation in C++20, a vector
variable with static storage duration might be manifestly
constant-evaluated, so we properly try to constant-evaluate its initializer.
But it can never succeed since the result will always refer to the result of
operator new, so trying is a waste of time. Potentially a large waste of
time for a large vector, as in the testcase in the PR.
So, let's recognize this case and skip trying constant-evaluation. I do
this only for the case of an integer argument, as that's the case that's
easy to write but slow to (fail to) evaluate.
In the test, I use dg-timeout-factor to lower the default timeout from 300
seconds to 15; on my laptop, compilation without the patch takes about 20
seconds versus about 2 with the patch.
PR c++/113835
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_outermost_constant_expr): Bail out early
for std::vector(N).
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/constexpr-vector1.C: New test.
|
|
|
|
In the three-parameter version of satisfy_declaration_constraints, when
't' isn't the most general template, then 't' won't correspond with
'args' after we augment the latter via add_outermost_template_args, and
so the instantiation context that we push via push_tinst_level isn't
quite correct: 'args' is a complete set of template arguments, but 't'
is not necessarily the most general template. This manifests as
misleading diagnostic context lines when issuing a satisfaction failure
error, e.g. the below testcase without this patch we emit:
In substitution of '... void A<int>::f<U>() ... [with U = int]'
and with this patch we emit:
In substitution of '... void A<int>::f<U>() ... [with U = char]'.
This patch fixes this by passing the original 'args' to push_tinst_level,
which ought to properly correspond to 't'.
PR c++/99214
gcc/cp/ChangeLog:
* constraint.cc (satisfy_declaration_constraints): Pass the
original ARGS to push_tinst_level.
gcc/testsuite/ChangeLog:
* g++.dg/concepts/diagnostic20.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
|
|
For the testcase from this PR, checking
static_assert(0 == big_calc());
takes twice as much time as
constexpr int ret = big_calc();
static_assert(0 == ret);
ultimately because in the former, we first constant evaluate big_calc()
with mce_unknown (as part of warning-dependent folding from
cp_build_binary_op). We then constant evaluate it a second time, with
mce_true, during finish_static_assert. The result of the first
evaluation isn't reused because of the different mce_value, which in
general can give a different result.
But big_calc() here doesn't depend on mce_value at all (i.e. there's no if
consteval or __builtin_is_constant_evaluated calls, nested or otherwise)
so we should be able to reuse the result in such cases. Specifically if a
constexpr call with mce_unknown succeeds, we can safely reuse the result
during a subsequent mce_true or mce_false evaluation.
This patch implements this by also caching a successful mce_unknown call
result into the corresponding mce_true and mce_false slots, so that such
a subsequent evaluation effectively reuses the mce_unknown result. To
make it more convenient to access the cache slot for the same call with
different mce_value, this patch gives each constexpr_call entry three
result slots, one per mce_value, instead of having a distinct
constexpr_call entry for each mce_value. And we can no longer use
NULL_TREE to denote the call is in progress; instead use unknown_type_node.
After this patch compile time for the above two fragments is the same.
PR c++/115639
gcc/cp/ChangeLog:
* constexpr.cc (struct constexpr_call): Add NSDMIs to each
field. Replace 'result' data member with 3-element 'results'
array and a 'result' accessor function. Remove
'manifestly_const_eval' data member.
(constexpr_call_hasher::equal): Adjust after constexpr_call
layout change.
(cxx_eval_call_expression): Likewise. Define some local
variables closer to their first use. Use unknown_type_node
instead of NULL_TREE as the "in progress" result. After
successully evaluating a call with mce_unknown, also cache the
result in the corresponding mce_true and mce_false slots.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
My change in r15-9216 broke the case where we imported an uninstantiated
defaulted function over the top of one we had already finished. This
patch ensures that we don't error for mismatches in this case.
gcc/cp/ChangeLog:
* module.cc (trees_in::is_matching_decl): Don't check for
mismatches when importing a DECL_MAYBE_DELETED function over one
that's already finished.
gcc/testsuite/ChangeLog:
* g++.dg/modules/noexcept-4_a.H: New test.
* g++.dg/modules/noexcept-4_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
This patch also rephrases the diagnostics to talk about "imported
declarations" rather than "global module declarations", since as the
FIXME noted we can also get mismatches with some declarations attached
to modules. Ideally I'd like to revisit the way this is structured
entirely but that won't be appropriate for GCC 15.
gcc/cp/ChangeLog:
* module.cc (trees_in::is_matching_decl): Add custom errors for
different kinds of mismatches.
gcc/testsuite/ChangeLog:
* g++.dg/modules/lambda-8_b.C: Adjust error.
* g++.dg/modules/leg-merge-4_c.C: Likewise.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
|
|
|
|
This patch improves upon r15-6052-g12de1942a0a673 by performing prvalue
folding with mce_false rather than mce_unknown when it's safe to do so
(i.e. ff_mce_false is set), so that we can also fold temporary initializers
that call is_constant_evaluated etc.
In passing I noticed constexpr-prvalue1.C could more precisely verify the
optimization happened by inspecting what the front end spits out instead
of inspecting the optimized assembly -- that there's no constructor call
doesn't necessarily imply the constructor has been completely folded away,
only that its body has been inlined.
PR c++/116416
gcc/cp/ChangeLog:
* constexpr.cc (maybe_constant_init_1): Generalize type of
of manifestly_const_eval parameter from bool to mce_value.
(maybe_constant_init): Define 3-parameter version taking a
manifestly_const_eval instead of bool parameter.
(cxx_constant_init): Adjust.
* cp-gimplify.cc (cp_fold_r) <case TARGET_EXPR>: Pass mce_false
to maybe_constant_init during prvalue folding if ff_mce_false is
set.
* cp-tree.h (maybe_constant_init): Declare new overload.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/constexpr-prvalue1.C: Adjust to instead inspect
the 'original' dump.
* g++.dg/cpp1y/constexpr-prvalue1a.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
|
|
Because of the __builtin_is_constant_evaluated, maybe_constant_init in
expand_default_init fails, so the constexpr constructor isn't folded until
cp_fold, which then calls cp_build_init_expr_for_ctor, which builds a
COMPOUND_EXPR in case the enclosing expression is relying on the ARM
behavior of returning 'this'.
As in other places, avoid -Wunused-value on artificial COMPOUND_EXPR.
PR c++/114970
gcc/cp/ChangeLog:
* cp-gimplify.cc (cp_build_init_expr_for_ctor): Suppress warnings on
return_this COMPOUND_EXPR.
gcc/testsuite/ChangeLog:
* g++.dg/opt/is_constant_evaluated4.C: New test.
|
|
|
|
tsubst_stmt already registers a local capture proxy as a
local_specialization of both an outer capture proxy and the captured
variable; we also need to do that in add_extra_args.
PR c++/119345
gcc/cp/ChangeLog:
* pt.cc (add_extra_args): Also register a specialization
of the captured variable.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-targ14.C: New test.
|
|
With inherited CTAD the set of guides may be a two-dimensional overload
set (i.e. OVERLOADs of OVERLOADs) so alias_ctad_tweaks (which also does
the inherited CTAD transformation) needs to use the 2D-aware lkp_iterator
instead of ovl_iterator, or better yet use the more idiomatic lkp_range.
PR c++/119687
gcc/cp/ChangeLog:
* pt.cc (alias_ctad_tweaks): Use lkp_range / lkp_iterator
instead of ovl_iterator.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/class-deduction-inherited8.C: New test.
Reviewed-by: Jason Merill <jason@redhat.com>
|
|
[PR119684]
These pp_printf/pp_verbatim format strings should be gcc-internal-format,
they use the pretty-print.cc format specifier handling rather than libc
*printf, but pp_printf/pp_verbatim are intentionally not handled through
exgettext because not everything done through them should be translated
(e.g. its use for dump files shouldn't be).
In addition, composing translatable messages from
"in requirements " and later on "with " might make it harder to be
translated.
I've verified these strings (at least those which don't use format
specifiers added post GCC 4.3 which gettext doesn't handle) are properly
marked as gcc-internal-format in gcc.pot. The lack of that caused
ICEs on German translation of the "%s%s%sIn instantiation of %q#D:\n"
message because it contained too many %s.
2025-04-10 Jakub Jelinek <jakub@redhat.com>
PR translation/119684
* error.cc (cp_print_error_function): Use G_ instead of _ for
pp_printf arguments.
(function_category): Use G_ instead of _.
(print_instantiation_full_context): Use G_ instead of _ in pp_verbatim
arguments.
(print_location): Likewise.
(print_instantiation_partial_context): Likewise.
(maybe_print_constexpr_context): Likewise.
(print_constrained_decl_info): Use G_() around pp_verbatim argument.
(print_concept_check_info): Likewise.
(print_constraint_context_head): Likewise.
(print_requires_expression_info): Likewise. Merge separate pp_verbatim
"in requirements " and "with " into one with conditional messages.
|
|
Here when we went to mangle the constraints of from<0>, the outer lambda has
no mangling scope, but the inner one was treated as having the outer one as
its scope. And mangling the outer one means mangling its constraints, which
include the inner one. So infinite recursion.
But a lambda closure type isn't a scope that anything should have for
mangling, the inner lambda should also have no mangling scope.
PR c++/119175
gcc/cp/ChangeLog:
* mangle.cc (decl_mangling_context): Look through lambda type.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-lambda23.C: New test.
|
|
|
|
Here we substitute into the inner lambda twice, first during default
argument substitution for the outer template parameters, then during
that for the inner template parameters.
For the second testcase (which is easier to follow/debug), the first
substitution into the inner lambda is with the template arguments
{0, NULL_TREE}, which we defer because it's an incremental substitution.
For the second and final substitution we have the template arguments
{1, NULL_TREE}, which we try combining via add_extra_args and ICE on
the checking assert because TREE_STATIC isn't set on the deferred
arguments but the template arguments are considered dependent.
The template arguments aren't dependent however -- they're just
incomplete because when we deferred them we were in the middle of
deduction, and we consider a NULL_TREE template argument as dependent.
If we remove this checking assert, we go on to correctly merge the
template arguments into {{0, NULL_TREE}, {1, NULL_TREE}}. So this
patch just removes this imprecise assert.
PR c++/119574
gcc/cp/ChangeLog:
* pt.cc (add_extra_args): Remove checking assert.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-targ13.C: New test.
* g++.dg/cpp2a/lambda-targ13a.C: New test.
* g++.dg/cpp2a/lambda-targ13b.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
When normalizing is_foo for <T>, we get to normalizing
callable<decltype(...),T> for <T,foo>, which means substituting <T,foo> into
<decltype(...),T>.
Since r14-9938, because in_template_context is false we return the lambda
unchanged, just with LAMBDA_EXPR_EXTRA_ARGS set, so the closure type still
refers to the is_specialization_of tparms in its CLASSTYPE_TEMPLATE_INFO.
So then in normalize_atom caching find_template_parameters walks over the
parameter mapping; any_template_parm_r walks into the TREE_TYPE of a
LAMBDA_EXPR without considering EXTRA_ARGS and finds a template parm from
the wrong parameter list.
But since r15-3530 we expect to set tf_partial when substituting with
dependent arguments, so we should set that when normalizing. And then
tf_partial causes TREE_STATIC to be set on the EXTRA_ARGS, meaning that
those args will replace all the template parms in the rest of the lambda, so
we can walk just the EXTRA_ARGS and ignore the rest.
PR c++/118698
gcc/cp/ChangeLog:
* constraint.cc (struct norm_info): Add tf_partial.
* pt.cc (any_template_parm_r): Handle LAMBDA_EXPR_EXTRA_ARGS.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-lambda22.C: New test.
|
|
|
|
Here, instantiating B<short> means instantiating A<short>, which means
instantiating B<short>. And then when we go to register the initial
instantiation, it conflicts with the inner one. Fixed by checking after
tsubst whether there's already something in the hash table. We already did
something much like this in tsubst_decl, but that doesn't handle this case.
While I was here, I noticed that we had a pop_deferring_access_checks on one
early exit but not another, and since I wanted to add yet another I switched
to using deferring_access_check_sentinel.
PR c++/117530
gcc/cp/ChangeLog:
* pt.cc (instantiate_template): Check retrieve_specialization after
tsubst.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-uneval27.C: New test.
|
|
|
|
Value-initialization built an AGGR_INIT_EXPR to set AGGR_INIT_ZERO_FIRST on.
Passing that AGGR_INIT_EXPR to maybe_constant_value returned a TARGET_EXPR,
which potential_constant_expression_1 mistook for a temporary.
We shouldn't add a TARGET_EXPR to the AGGR_INIT_EXPR in this case, just like
we already avoid adding it to CONSTRUCTOR or CALL_EXPR.
PR c++/119652
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_outermost_constant_expr): Also don't add a
TARGET_EXPR around AGGR_INIT_EXPR.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/constinit20.C: New test.
|
|
|
|
Here during maybe_dependent_member_ref for accepted_type<_Up>, we
correctly don't strip the typedef because it's a complex one (its
defaulted template parameter isn't used in its definition) and so
we recurse to consider its corresponding TYPE_DECL.
We then incorrectly decide to not rewrite this use because of the
TYPENAME_TYPE shortcut. But I don't think this shortcut should apply to
a typedef TYPE_DECL.
PR c++/118626
gcc/cp/ChangeLog:
* pt.cc (maybe_dependent_member_ref): Restrict TYPENAME_TYPE
shortcut to non-typedef TYPE_DECL.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/class-deduction-alias25a.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
Here during maybe_dependent_member_ref (as part of CTAD rewriting
for the variant constructor) for __accepted_type<_Up> we strip this
alias all the way to type _Nth_type<__accepted_index<_Up>>, for which
we return NULL since _Nth_type is at namespace scope and so no
longer needs rewriting.
Note that however the template argument __accepted_index<_Up> of this
stripped type _does_ need rewriting (since it specializes a variable
template from the current instantiation). We end up not rewriting this
variable template reference at any point however because upon returning
NULL, the caller (tsubst) proceeds to substitute the original form of
the type __accepted_type<_Up>, which doesn't directly refer to
__accepted_index. This later leads to an ICE during subsequent alias
CTAD rewriting of this guide that contains a non-rewritten reference
to __accepted_index.
So when maybe_dependent_member_ref decides to not rewrite a class-scope
alias that's been stripped, the caller needs to commit to substituting
the stripped type rather than the original type. This patch essentially
implements that by making maybe_dependent_member_ref call tsubst itself
in that case.
PR c++/118626
gcc/cp/ChangeLog:
* pt.cc (maybe_dependent_member_ref): Substitute and return the
stripped type if we decided to not rewrite it directly.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/class-deduction-alias25.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
|
|
Here the implicit use of 'this' in inner.size() template argument was
being rejected despite P2280R4 relaxations, due to the special *this
handling in the INDIRECT_REF case of potential_constant_expression_1.
This handling was originally added by r196737 as part of fixing PR56481,
and it seems obsolete especially in light of P2280R4. There doesn't
seem to be a good reason that we need to handle *this specially from
other dereferences.
This patch therefore removes this special handling. As a side benefit
we now correctly reject some *reinterpret_cast<...>(...) constructs
earlier, via p_c_e_1 rather than via constexpr evaluation (because the
removed STRIP_NOPS step meant we'd overlook such casts), which causes a
couple of diagnostic changes (for the better).
PR c++/118249
gcc/cp/ChangeLog:
* constexpr.cc (potential_constant_expression_1)
<case INDIRECT_REF>: Remove obsolete *this handling.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-reinterpret2.C: Expect error at
call site of the non-constexpr functions.
* g++.dg/cpp23/constexpr-nonlit12.C: Likewise.
* g++.dg/cpp0x/constexpr-ref14.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
In this testcase, the use of __FUNCTION__ is within a function parameter
scope, the lambda's. And P1787 changed __func__ to live in the parameter
scope. But [basic.scope.pdecl] says that the point of declaration of
__func__ is immediately before {, so in the trailing return type it isn't in
scope yet, so this __FUNCTION__ should refer to foo().
Looking first for a block scope, then a function parameter scope, gives us
the right result.
PR c++/118629
gcc/cp/ChangeLog:
* name-lookup.cc (pushdecl_outermost_localscope): Look for an
sk_block.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/lambda/lambda-__func__3.C: New test.
|
|
|
|
When adding TU_LOCAL_ENTITY in r15-6379 I neglected to add it to
cp_tree_node_structure, so garbage collection was crashing on it.
PR c++/119564
gcc/cp/ChangeLog:
* decl.cc (cp_tree_node_structure): Add TU_LOCAL_ENTITY; fix
formatting.
gcc/testsuite/ChangeLog:
* g++.dg/modules/gc-3_a.C: New test.
* g++.dg/modules/gc-3_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
Modules streaming walks decls multiple times, first as a non-streaming
walk to find dependencies, and then later to actually emit the decls.
The first walk needs to be done to note locations that will be emitted.
In the PR we are getting a checking ICE because we are streaming a decl
that we didn't initially walk when collecting dependencies, so the
location isn't in the noted locations map. This is because in decl_node
we have a branch where a PARM_DECL that hasn't previously been
referenced gets walked by value only if 'streaming_p ()' is true.
The true root cause here is that the decltype(v) in the testcase refers
to a different PARM_DECL from the one in the declaration that we're
streaming; it's the PARM_DECL from the initial forward-declaration, that
we're not streaming. A proper fix would be to ensure that it gets
remapped to the decl in the definition we're actually emitting, but for
now this workaround fixes the bug (and any other bugs that might
manifest similarly).
PR c++/119608
gcc/cp/ChangeLog:
* module.cc (trees_out::decl_node): Maybe require by-value
walking not just when streaming.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr119608_a.C: New test.
* g++.dg/modules/pr119608_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
In the linked PR, we're importing over a DECL_MAYBE_DELETED decl with a
decl that has already been instantiated. This patch ensures that the
needed bits are propagated across and that DECL_MAYBE_DELETED is cleared
from the existing decl, so that later synthesize_method doesn't crash
due to a definition unexpectedly already existing.
PR c++/119462
gcc/cp/ChangeLog:
* module.cc (trees_in::is_matching_decl): Propagate exception
spec and constexpr to DECL_MAYBE_DELETED; clear if appropriate.
gcc/testsuite/ChangeLog:
* g++.dg/modules/noexcept-3_a.C: New test.
* g++.dg/modules/noexcept-3_b.C: New test.
* g++.dg/modules/noexcept-3_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
Since r10-7441 we set processing_template_decl in a requires-expression so
that we can use tsubst_expr to evaluate the requirements, but that confuses
lambdas terribly; begin_lambda_type silently returns error_mark_node and we
continue into other failures. This patch clears processing_template_decl
again while we're defining the closure and op() function, so it only remains
set while parsing the introducer (i.e. any init-captures) and building the
resulting object. This properly avoids trying to create another lambda in
tsubst_lambda_expr.
PR c++/99546
PR c++/113925
PR c++/106976
PR c++/109961
PR c++/117336
gcc/cp/ChangeLog:
* lambda.cc (build_lambda_object): Handle fake
requires-expr processing_template_decl.
* parser.cc (cp_parser_lambda_expression): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-requires2.C: New test.
* g++.dg/cpp2a/lambda-requires3.C: New test.
* g++.dg/cpp2a/lambda-requires4.C: New test.
* g++.dg/cpp2a/lambda-requires5.C: New test.
|
|
Here we wrongly reject the type-requirement at parse time due to its use
of the constraint variable 't' within a template argument (an evaluated
context). Fix this simply by refining the "use of parameter outside
function body" error path to exclude constraint variables.
PR c++/104255 tracks the same issue for function parameters, but fixing
that would be more involved, requiring changes to the PARM_DECL case of
tsubst_expr.
PR c++/117849
gcc/cp/ChangeLog:
* semantics.cc (finish_id_expression_1): Allow use of constraint
variable outside an unevaluated context.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-requires41.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
|
|
Compiling the testcase in this PR uses 2.5x more memory and 6x more
time ever since r14-5979 which implements P2280R4. This is because
our speculative constexpr folding now does a lot more work trying to
fold ultimately non-constant calls to constexpr functions, and in turn
produces a lot of garbage. We do sometimes successfully fold more
thanks to P2280R4, but it seems to be trivial stuff like calls to
std::array::size or std::addressof. The benefit of P2280 therefore
doesn't seem worth the cost during speculative constexpr folding, so
this patch restricts the paper to only manifestly-constant evaluation.
PR c++/119387
gcc/cp/ChangeLog:
* constexpr.cc (p2280_active_p): New.
(cxx_eval_constant_expression) <case VAR_DECL>: Use it to
restrict P2280 relaxations.
<case PARM_DECL>: Likewise.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
std/format/string.cc and a few other libstdc++ tests were failing with
module std with undefined references to __failed_to_parse_format_spec. This
turned out to be because since r15-8012 we don't end up calling
note_vague_linkage_fn for functions loaded after at_eof is set.
But once import_export_decl decides on COMDAT linkage, we should be able to
just clear DECL_EXTERNAL and let cgraph take it from there.
I initially made this change in import_export_decl, but decided that for GCC
15 it would be safer to limit the change to modules. For GCC 16 I'd like to
do away with DECL_NOT_REALLY_EXTERN entirely, it's been obsolete since
cgraphunit in 2003.
gcc/cp/ChangeLog:
* module.cc (module_state::read_cluster)
(post_load_processing): Clear DECL_EXTERNAL if DECL_COMDAT.
|
|
When considering an op== as a rewrite target, we need to disqualify it if
there is a matching op!= in the same scope. But add_candidates was assuming
that we could use the same set of op!= for all op==, which is wrong if
arg-dep lookup finds op== in multiple namespaces.
This broke 20_util/optional/relops/constrained.cc if the order of the ADL
set changed.
gcc/cp/ChangeLog:
* call.cc (add_candidates): Re-lookup ne_fns if we move into
another namespace.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/spaceship-rewrite6.C: New test.
|
|
The following testcase ICEs (the embed one actually doesn't but
dereferences random uninitialized pointer far after allocated memory)
because of a typo. In the RAW_DATA_CST handling of list conversion
where there are conversions to something other than
initializer_list<{{,un}signed ,}char>, the code now calls
implicit_conversion for all the RAW_DATA_CST elements and stores them
into subsubconvs array.
The next loop (done in a separate loop because subsubconvs[0] is
handled differently) attempts to do the
for (i = 0; i < len; ++i)
{
conversion *sub = subconvs[i];
if (sub->rank > t->rank)
t->rank = sub->rank;
if (sub->user_conv_p)
t->user_conv_p = true;
if (sub->bad_p)
t->bad_p = true;
}
rank/user_conv_p/bad_p merging, but I mistyped the index, the loop
iterates with j iterator and i is subconvs index, so the loop effectively
doesn't do anything interesting except for merging from one of the
subsubconvs element, if lucky within the subsubconvs array, if unlucky
not even from inside of the array.
The following patch fixes that.
2025-04-03 Andrew Pinski <quic_apinski@quicinc.com>
Jakub Jelinek <jakub@redhat.com>
PR c++/119563
* call.cc (build_list_conv): Fix a typo in loop gathering
summary information from subsubconvs.
* g++.dg/cpp0x/pr119563.C: New test.
* g++.dg/cpp/embed-26.C: New test.
|
|
|
|
As noted in PR 118965, the initial interop implementation overlooked
the requirement in the OpenMP spec that at least one of the "target"
and "targetsync" modifiers is required in both the interop construct
init clause and the declare variant append_args clause.
Adding the check was fairly straightforward, but it broke about a
gazillion existing test cases. In particular, things like "init (x, y)"
which were previously accepted (and tested for being accepted) aren't
supposed to be allowed by the spec, much less things like "init (target)"
where target was previously interpreted as a variable name instead of a
modifier. Since one of the effects of the change is that at least one
modifier is always required, I found that deleting all the code that was
trying to detect and handle the no-modifier case allowed for better
diagnostics.
gcc/c/ChangeLog
PR middle-end/118965
* c-parser.cc (c_parser_omp_clause_init_modifiers): Adjust
error message.
(c_parser_omp_clause_init): Remove code for recognizing clauses
without modifiers. Diagnose missing target/targetsync modifier.
(c_finish_omp_declare_variant): Diagnose missing target/targetsync
modifier.
gcc/cp/ChangeLog
PR middle-end/118965
* parser.cc (c_parser_omp_clause_init_modifiers): Adjust
error message.
(cp_parser_omp_clause_init): Remove code for recognizing clauses
without modifiers. Diagnose missing target/targetsync modifier.
(cp_finish_omp_declare_variant): Diagnose missing target/targetsync
modifier.
gcc/fortran/ChangeLog
PR middle-end/118965
* openmp.cc (gfc_parser_omp_clause_init_modifiers): Fix some
inconsistent code indentation. Remove code for recognizing
clauses without modifiers. Diagnose prefer_type without a
following paren. Adjust error message for an unrecognized modifier.
Diagnose missing target/targetsync modifier.
(gfc_match_omp_init): Fix more inconsistent code indentation.
gcc/testsuite/ChangeLog
PR middle-end/118965
* c-c++-common/gomp/append-args-1.c: Add target/targetsync
modifiers so tests do what they were previously supposed to do.
Adjust expected output.
* c-c++-common/gomp/append-args-7.c: Likewise.
* c-c++-common/gomp/append-args-8.c: Likewise.
* c-c++-common/gomp/append-args-9.c: Likewise.
* c-c++-common/gomp/interop-1.c: Likewise.
* c-c++-common/gomp/interop-2.c: Likewise.
* c-c++-common/gomp/interop-3.c: Likewise.
* c-c++-common/gomp/interop-4.c: Likewise.
* c-c++-common/gomp/pr118965-1.c: New.
* c-c++-common/gomp/pr118965-2.c: New.
* g++.dg/gomp/append-args-1.C: Add target/targetsync modifiers
and adjust expected output.
* g++.dg/gomp/append-args-2.C: Likewise.
* g++.dg/gomp/append-args-6.C: Likewise.
* g++.dg/gomp/append-args-7.C: Likewise.
* g++.dg/gomp/append-args-8.C: Likewise.
* g++.dg/gomp/interop-5.C: Likewise.
* gfortran.dg/gomp/append_args-1.f90: Add target/targetsync
modifiers and adjust expected output.
* gfortran.dg/gomp/append_args-2.f90: Likewise.
* gfortran.dg/gomp/append_args-3.f90: Likewise.
* gfortran.dg/gomp/append_args-4.f90: Likewise.
* gfortran.dg/gomp/interop-1.f90: Likewise.
* gfortran.dg/gomp/interop-2.f90: Likewise.
* gfortran.dg/gomp/interop-3.f90: Likewise.
* gfortran.dg/gomp/interop-4.f90: Likewise.
* gfortran.dg/gomp/pr118965-1.f90: New.
* gfortran.dg/gomp/pr118965-2.f90: New.
|
|
|
|
[PR119551]
An inline variable has vague linkage, and needs to be conditionally
emitted in TUs that reference it. Unfortunately this clashes with
[basic.link] p14.2, which says that we ignore the initialisers of all
variables (including inline ones), since importers will not have access
to the referenced TU-local entities to write the definition.
This patch makes such exposures be ill-formed. One case that continues
to work is if the exposure is part of the dynamic initialiser of an
inline variable; in such cases, the definition has been built as part of
the module interface unit anyway, and importers don't need to write it
out again, so such exposures are "harmless".
PR c++/119551
gcc/cp/ChangeLog:
* module.cc (trees_out::write_var_def): Only ignore non-inline
variable initializers.
gcc/testsuite/ChangeLog:
* g++.dg/modules/internal-5_a.C: Add cases that should be
ignored.
* g++.dg/modules/internal-5_b.C: Test these new cases, and make
the testcase more robust.
* g++.dg/modules/internal-11.C: New test.
* g++.dg/modules/internal-12_a.C: New test.
* g++.dg/modules/internal-12_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
|
