| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
__atomic_{compare_}exchange
On Fri, Feb 16, 2024 at 01:51:54PM +0000, Jonathan Wakely wrote:
> Ah, although __atomic_compare_exchange only takes pointers, the
> compiler replaces that with a call to __atomic_compare_exchange_n
> which takes the newval by value, which presumably uses an 80-bit FP
> register and so the padding bits become indeterminate again.
The problem is that __atomic_{,compare_}exchange lowering if it has
a supported atomic 1/2/4/8/16 size emits code like:
_3 = *p2;
_4 = VIEW_CONVERT_EXPR<I_type> (_3);
so if long double or some small struct etc. has some carefully filled
padding bits, those bits can be lost on the assignment. The library call
for __atomic_{,compare_}exchange would actually work because it woiuld
load the value from memory using integral type or memcpy.
E.g. on
void
foo (long double *a, long double *b, long double *c)
{
__atomic_compare_exchange (a, b, c, false, __ATOMIC_RELAXED, __ATOMIC_RELAXED);
}
we end up with -O0 with:
fldt (%rax)
fstpt -48(%rbp)
movq -48(%rbp), %rax
movq -40(%rbp), %rdx
i.e. load *c from memory into 387 register, store it back to uninitialized
stack slot (the padding bits are now random in there) and then load a
__uint128_t (pair of GPR regs). The problem is that we first load it using
whatever type the pointer points to and then VIEW_CONVERT_EXPR that value:
p2 = build_indirect_ref (loc, p2, RO_UNARY_STAR);
p2 = build1 (VIEW_CONVERT_EXPR, I_type, p2);
The following patch fixes that by creating a MEM_REF instead, with the
I_type type, but with the original pointer type on the second argument for
aliasing purposes, so we actually preserve the padding bits that way.
With this patch instead of the above assembly we emit
movq 8(%rax), %rdx
movq (%rax), %rax
I had to add support for MEM_REF in pt.cc, though with the assumption
that it has been already originally created with non-dependent
types/operands (which is the case here for the __atomic*exchange lowering).
2024-03-08 Jakub Jelinek <jakub@redhat.com>
gcc/c-family/
* c-common.cc (resolve_overloaded_atomic_exchange): Instead of setting
p1 to VIEW_CONVERT_EXPR<I_type> (*p1), set it to MEM_REF with p1 and
(typeof (p1)) 0 operands and I_type type.
(resolve_overloaded_atomic_compare_exchange): Similarly for p2.
gcc/cp/
* pt.cc (tsubst_expr): Handle MEM_REF.
gcc/testsuite/
* g++.dg/ext/atomic-5.C: New test.
|
|
DWARF5 added DW_AT_export_symbols both for use on inline namespaces (where
we emit it), but also on anonymous unions/structs (and we didn't emit that
attribute there).
The following patch fixes it.
2024-03-08 Jakub Jelinek <jakub@redhat.com>
PR debug/113918
gcc/
* dwarf2out.cc (gen_field_die): Emit DW_AT_export_symbols
on anonymous unions or structs for -gdwarf-5 or -gno-strict-dwarf.
gcc/c/
* c-tree.h (c_type_dwarf_attribute): Declare.
* c-objc-common.h (LANG_HOOKS_TYPE_DWARF_ATTRIBUTE): Redefine.
* c-objc-common.cc: Include dwarf2.h.
(c_type_dwarf_attribute): New function.
gcc/cp/
* cp-objcp-common.cc (cp_type_dwarf_attribute): Return 1
for DW_AT_export_symbols on anonymous structs or unions.
gcc/testsuite/
* c-c++-common/dwarf2/pr113918.c: New test.
|
|
The simple presence of ellipsis as next token after the parameter
declaration doesn't imply it is a parameter pack, it sometimes is, e.g.
if its type is a pack, but sometimes is not and in that case it acts
the same as if the next tokens were , ... instead of just ...
The xobj param cannot be a function parameter pack though treats both
the declarator->parameter_pack_p and token->type == CPP_ELLIPSIS as
sufficient conditions for the error. The conditions for CPP_ELLIPSIS
are done a little bit later in the same function and complex enough that
IMHO shouldn't be repeated, on the other side for the
declarator->parameter_pack_p case we clear that flag for xobj params
for error recovery reasons.
This patch just moves the diagnostics later (after the CPP_ELLIPSIS handling)
and changes the error recovery behavior by pretending the this specifier
didn't appear if an error is reported.
2024-03-08 Jakub Jelinek <jakub@redhat.com>
PR c++/113802
* parser.cc (cp_parser_parameter_declaration): Move the xobj_param_p
pack diagnostics after ellipsis handling and if an error is reported,
pretend this specifier didn't appear. Formatting fix.
* g++.dg/cpp23/explicit-obj-diagnostics3.C (S0, S1, S2, S3, S4): Don't
expect any diagnostics on f and fd member function templates, add
similar templates with ...Selves instead of Selves as k and kd and
expect diagnostics for those. Expect extra diagnostics in error
recovery for g and gd member function templates.
|
|
|
|
We currently always stream DECL_INTERFACE_KNOWN, which is needed since
many kinds of declarations already have their interface determined at
parse time. But for vtables and type-info declarations we need to
re-evaluate on stream-in as whether they need to be emitted or not
changes in each TU, so this patch clears DECL_INTERFACE_KNOWN on these
kinds of declarations so that they can go through 'import_export_decl'
again.
Note that the precise details of the virt-2 tests will need to change
when we implement the resolution of [1], for now I just updated the test
to not fail with the new (current) semantics.
[1]: https://github.com/itanium-cxx-abi/cxx-abi/pull/171
PR c++/114229
gcc/cp/ChangeLog:
* module.cc (trees_out::core_bools): Redetermine
DECL_INTERFACE_KNOWN on stream-in for vtables and tinfo.
* decl2.cc (import_export_decl): Add fixme for ABI changes with
module vtables and tinfo.
gcc/testsuite/ChangeLog:
* g++.dg/modules/virt-2_b.C: Update test to acknowledge that we
now emit vtables here too.
* g++.dg/modules/virt-3_a.C: New test.
* g++.dg/modules/virt-3_b.C: New test.
* g++.dg/modules/virt-3_c.C: New test.
* g++.dg/modules/virt-3_d.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
|
|
Alias templates are weird in that their specializations can appear in
both decl_specializations and type_specializations. They're always in
the decl table, and additionally appear in the type table only at parse
time via finish_template_type. There seems to be no good reason for
them to appear in both tables, and the code paths end up stepping over
each other in particular for a partial instantiation such as
A<B>::key_arg<T> in the below modules testcase: the type code path
(lookup_template_class) wants to set TI_TEMPLATE to the most general
template whereas the decl code path (tsubst_template_decl called during
instantiation of A<B>) already set TI_TEMPLATE to the partially
instantiated TEMPLATE_DECL. This TI_TEMPLATE change ends up confusing
modules which decides to stream the logically equivalent TYPE_DECL and
TEMPLATE_DECL for this partial instantiation separately.
This patch fixes this by making lookup_template_class dispatch to
instantiate_alias_template early for alias template specializations.
In turn we now add such specializations only to the decl table. This
admits some nice simplification in the modules code which otherwise has
to cope with such specializations appearing in both tables.
PR c++/103994
gcc/cp/ChangeLog:
* cp-tree.h (add_mergeable_specialization): Remove second
parameter.
* module.cc (depset::disc_bits::DB_ALIAS_TMPL_INST_BIT): Remove.
(depset::disc_bits::DB_ALIAS_SPEC_BIT): Remove.
(depset::is_alias_tmpl_inst): Remove.
(depset::is_alias): Remove.
(merge_kind::MK_tmpl_alias_mask): Remove.
(merge_kind::MK_alias_spec): Remove.
(merge_kind_name): Remove entries for alias specializations.
(trees_out::core_vals) <case TEMPLATE_DECL>: Adjust after
removing is_alias_tmpl_inst.
(trees_in::decl_value): Adjust add_mergeable_specialization
calls.
(trees_out::get_merge_kind) <case depset::EK_SPECIALIZATION>:
Use MK_decl_spec for alias template specializations.
(trees_out::key_mergeable): Simplify after MK_tmpl_alias_mask
removal.
(depset::hash::make_dependency): Adjust after removing
DB_ALIAS_TMPL_INST_BIT.
(specialization_add): Don't allow alias templates when !decl_p.
(depset::hash::add_specializations): Remove now-dead code
accomodating alias template specializations in the type table.
* pt.cc (lookup_template_class): Dispatch early to
instantiate_alias_template for alias templates. Simplify
accordingly.
(add_mergeable_specialization): Remove alias_p parameter and
simplify accordingly.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr99425-1_b.H: s/alias/decl in dump scan.
* g++.dg/modules/tpl-alias-1_a.H: Likewise.
* g++.dg/modules/tpl-alias-2_a.H: New test.
* g++.dg/modules/tpl-alias-2_b.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
The unreduced testcase from PR110730 crashes at runtime ultimately
because we don't stream the abi_tag attribute on inline namespaces and
so the filesystem::current_path() call resolves to the non-C++11 ABI
version even though the C++11 ABI is active, leading to a crash when
destroying the path temporary (which contains an std::string member).
Similar story for the PR105512 testcase.
While we do stream the DECL_ATTRIBUTES of all decls that go through
the generic tree streaming routines, it seems namespaces are streamed
separately from other decls and we don't use the generic routines for
them. So this patch makes us stream the abi_tag manually for (inline)
namespaces.
PR c++/110730
PR c++/105512
gcc/cp/ChangeLog:
* module.cc (module_state::write_namespaces): Stream the
abi_tag attribute of an inline namespace.
(module_state::read_namespaces): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/modules/hello-2_a.C: New test.
* g++.dg/modules/hello-2_b.C: New test.
* g++.dg/modules/namespace-6_a.H: New test.
* g++.dg/modules/namespace-6_b.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
lookup_and_finish_template_variable already has and uses the complain
parameter but it is not passing it down to mark_used so we got the
default tf_warning_or_error, which causes various problems when
lookup_and_finish_template_variable gets called with complain=tf_none.
PR c++/110031
gcc/cp/ChangeLog:
* pt.cc (lookup_and_finish_template_variable): Pass complain to
mark_used.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/inline-var11.C: New test.
|
|
In the linked PR the result of 'get_first_fn' is a USING_DECL against
the template parameter, to be filled in on instantiation. But we don't
actually need to get the first set of the member functions: it's enough
to know that we have a (possibly overloaded) member function at all.
PR c++/98356
gcc/cp/ChangeLog:
* typeck2.cc (cxx_incomplete_type_diagnostic): Don't assume
'member' will be a FUNCTION_DECL (or something like it).
gcc/testsuite/ChangeLog:
* g++.dg/pr98356.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
|
|
When streaming in a nested template-template parameter as in the
attached testcase, we end up reaching the containing template-template
parameter in 'tpl_parms_fini'. We should not set the DECL_CONTEXT to
this (nested) template-template parameter, as it should already be the
struct that the outer template-template parameter is declared on.
The precise logic for what DECL_CONTEXT should be for a template
template parameter in various situations seems rather obscure. Rather
than trying to determine the assumptions that need to hold, it seems
simpler to just always re-stream the DECL_CONTEXT as needed for now.
PR c++/98881
gcc/cp/ChangeLog:
* module.cc (trees_out::tpl_parms_fini): Stream out DECL_CONTEXT
for template template parameters.
(trees_in::tpl_parms_fini): Read it.
gcc/testsuite/ChangeLog:
* g++.dg/modules/tpl-tpl-parm-3.h: New test.
* g++.dg/modules/tpl-tpl-parm-3_a.H: New test.
* g++.dg/modules/tpl-tpl-parm-3_b.C: New test.
* g++.dg/modules/tpl-tpl-parm-3_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Patrick Palka <ppalka@redhat.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
|
|
Here we ICE because we call register_local_specialization while
local_specializations is null, so
local_specializations->put ();
crashes on null this. It's null since maybe_instantiate_noexcept calls
push_to_top_level which creates a new scope. Normally, I would have
guessed that we need a new local_specialization_stack. But here we're
dealing with an operand of a noexcept, which is an unevaluated operand,
and those aren't registered in the hash map. maybe_instantiate_noexcept
wasn't signalling that it's substituting an unevaluated operand though.
PR c++/114114
gcc/cp/ChangeLog:
* pt.cc (maybe_instantiate_noexcept): Save/restore
cp_unevaluated_operand, c_inhibit_evaluation_warnings, and
cp_noexcept_operand around the tsubst_expr call.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept84.C: New test.
|
|
[PR113629]
Unification for conversion operators (DEDUCE_CONV) doesn't perform
transformations like handling forwarding references. This is correct in
general, but not for xobj parameters, which should be handled "normally"
for the purposes of deduction: [temp.deduct.conv] only applies to the
return type of the conversion function.
PR c++/113629
gcc/cp/ChangeLog:
* pt.cc (type_unification_real): Only use DEDUCE_CONV for the
return type of a conversion function.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/explicit-obj-conv-op.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
Here the TEMPLATE_DECL representing the template friend declaration
naming B has class scope since the template B has class scope, but
get_merge_kind assumes all DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P
TEMPLATE_DECL have namespace scope and wrongly returns MK_named instead
of MK_local_friend for the friend.
gcc/cp/ChangeLog:
* module.cc (trees_out::get_merge_kind) <case depset::EK_DECL>:
Accomodate class-scope DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P
TEMPLATE_DECL. Consolidate IDENTIFIER_ANON_P cases.
gcc/testsuite/ChangeLog:
* g++.dg/modules/friend-7.h: New test.
* g++.dg/modules/friend-7_a.H: New test.
* g++.dg/modules/friend-7_b.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
|
|
Issuing a hard error when the GMF doesn't consist only of preprocessing
directives happens to be inconvenient for automated testcase reduction
via cvise. This patch relaxes this diagnostic into a pedwarn that can
be disabled with -Wno-global-module.
gcc/c-family/ChangeLog:
* c.opt (Wglobal-module): New warning.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_translation_unit): Relax GMF contents
error into a pedwarn.
gcc/ChangeLog:
* doc/invoke.texi (-Wno-global-module): Document.
gcc/testsuite/ChangeLog:
* g++.dg/modules/friend-6_a.C: Pass -Wno-global-module instead
of -Wno-pedantic. Remove now unnecessary preprocessing
directives from GMF.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
|
|
Currently a using-declaration bringing a name into its own namespace is
a no-op, except for functions. This prevents people from being able to
redeclare a name brought in from the GMF as exported, however, which
this patch fixes.
Apart from marking declarations as exported they are also now marked as
effectively being in the module purview (due to the using-decl) so that
they are properly processed, as 'add_binding_entity' assumes that
declarations not in the module purview cannot possibly be exported.
gcc/cp/ChangeLog:
* name-lookup.cc (walk_module_binding): Remove completed FIXME.
(do_nonmember_using_decl): Mark redeclared entities as exported
when needed. Check for re-exporting internal linkage types.
gcc/testsuite/ChangeLog:
* g++.dg/modules/using-12.C: New test.
* g++.dg/modules/using-13.h: New test.
* g++.dg/modules/using-13_a.C: New test.
* g++.dg/modules/using-13_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
|
|
|
|
For local enums defined in a non-template function or a function template
instantiation it seems we neglect to make the function depend on the enum
definition (which modules considers logically separate), which ultimately
causes the enum definition to not be properly streamed before uses
within the function definition are streamed.
The code responsible for noting such dependencies is
gcc/cp/module.cc
@@ -8784,17 +8784,6 @@ trees_out::decl_node (tree decl, walk_kind ref)
depset *dep = NULL;
if (streaming_p ())
dep = dep_hash->find_dependency (decl);
! else if (TREE_CODE (ctx) != FUNCTION_DECL
! || TREE_CODE (decl) == TEMPLATE_DECL
! || (dep_hash->sneakoscope && DECL_IMPLICIT_TYPEDEF_P (decl))
! || (DECL_LANG_SPECIFIC (decl)
! && DECL_MODULE_IMPORT_P (decl)))
! {
! auto kind = (TREE_CODE (decl) == NAMESPACE_DECL
! && !DECL_NAMESPACE_ALIAS (decl)
! ? depset::EK_NAMESPACE : depset::EK_DECL);
! dep = dep_hash->add_dependency (decl, kind);
! }
if (!dep)
{
and the condition there notably excludes local TYPE_DECLs from a
non-template-pattern function (when streaming a template pattern
we'll see be dealing with the corresponding TEMPLATE_DECL of the
local TYPE_DECL here, so we'll add the dependency).
Local classes on the other hand seem to work properly, but perhaps by
accident: with a local class we end up making the function depend on the
injected-class-name of the local class rather than the local class as a
whole because the injected-class-name satisfies the criteria (since its
context is the local class, not the function).
The 'sneakoscope' flag is set when walking a function declaration and
its purpose seems to be to catch a local type that escapes the function
via a deduced return type (so called voldemort types) and note a
dependency on them. But there seems to be no reason to restrict this
behavior to voldemort types, and indeed consistently noting the dependency
for all local types fixes these PRs (almost). So this patch gets rid of
this flag and enables the dependency tracking unconditionally.
This was nearly enough to make things work, except we now ran into
issues with the local TYPE_/CONST_DECL copies from the pre-gimplified
version of a constexpr function body during streaming. Rather than
making modules cope with this, it occurred to me that we don't need to
make copies of local types when saving the pre-gimplified body (and when
making further copies thereof); only VAR_DECLs etc need to be copied
(so that we don't conflate local variables from different recursive
calls to the same function during constexpr evaluation). So this patch
adjusts copy_fn accordingly.
PR c++/104919
PR c++/106009
gcc/cp/ChangeLog:
* module.cc (depset::hash::sneakoscope): Remove.
(trees_out::decl_node): Always add a dependency on a local type.
(depset::hash::find_dependencies): Remove sneakoscope stuff.
gcc/ChangeLog:
* tree-inline.cc (remap_decl): Handle copy_decl returning the
original decl.
(remap_decls): Handle remap_decl returning the original decl.
(copy_fn): Adjust copy_decl callback to skip TYPE_DECL and
CONST_DECL.
gcc/testsuite/ChangeLog:
* g++.dg/modules/tdef-7.h: Remove outdated comment.
* g++.dg/modules/tdef-7_b.C: Don't expect two TYPE_DECLs.
* g++.dg/modules/enum-13_a.C: New test.
* g++.dg/modules/enum-13_b.C: New test.
|
|
An implicit instantiation has an initializer depending on whether
DECL_INITIALIZED_P is set (like normal VAR_DECLs) which needs to be
written to ensure that consumers of header modules properly emit
definitions for these instantiations. This patch ensures that we
correctly fallback to checking this flag when DECL_INITIAL is not set
for a template instantiation.
For variables with non-trivial dynamic initialization, DECL_INITIAL can
be empty after 'split_nonconstant_init' but DECL_INITIALIZED_P is still
set; we need to check the latter to determine if we need to go looking
for a definition to emit (often in 'static_aggregates' here). This is
the case in the linked testcase.
However, for template specialisations (not instantiations?) we primarily
care about DECL_INITIAL; if the variable has initialization depending on
a template parameter then we'll need to emit that definition even though
it doesn't yet have DECL_INITIALIZED_P set; this is the case in e.g.
template <int N> int value = N;
As a drive-by fix, also ensures that the count of initializers matches
the actual number of initializers written. This doesn't seem to be
necessary for correctness in the current testsuite, but feels wrong and
makes debugging harder when initializers aren't properly written for
other reasons.
PR c++/114170
gcc/cp/ChangeLog:
* module.cc (has_definition): Fall back to DECL_INITIALIZED_P
when DECL_INITIAL is not set on a template.
(module_state::write_inits): Only increment count when
initializers are actually written.
gcc/testsuite/ChangeLog:
* g++.dg/modules/var-tpl-2_a.H: New test.
* g++.dg/modules/var-tpl-2_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
|
|
Modules streaming requires DECL_CONTEXT to be set for anything streamed.
This patch ensures that 'create_temporary_var' does set a DECL_CONTEXT
for these variables (such as the backing storage for initializer_lists)
even if not inside a function declaration.
PR c++/114005
gcc/cp/ChangeLog:
* init.cc (create_temporary_var): Use current_scope instead of
current_function_decl.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr114005_a.C: New test.
* g++.dg/modules/pr114005_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
|
|
Here after stream-in of the non-exported constexpr global 'A a' we call
maybe_register_incomplete_var, which we'd expect to be a no-op here but
it manages to take its second branch and pushes {a, NULL_TREE} onto
incomplete_vars. Later after defining B we ICE from complete_vars due
to this pushed NULL_TREE class context.
Judging by the two commits that introduced/modified this part of
maybe_register_incomplete_var, r196852 and r214333, it seems this second
branch is only concerned with constexpr static data members (whose
initializer may contain a pointer-to-member for a not-yet-complete class)
So this patch restricts this branch accordingly so it's not inadvertently
taken during stream-in.
gcc/cp/ChangeLog:
* decl.cc (maybe_register_incomplete_var): Restrict second
branch to static data members from a not-yet-complete class.
gcc/testsuite/ChangeLog:
* g++.dg/modules/cexpr-4_a.C: New test.
* g++.dg/modules/cexpr-4_b.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
Since -Wdangling-reference has false positives that can't be
prevented, we should offer an easy way to suppress the warning.
Currently, that is only possible by using a #pragma, either around the
enclosing class or around the call site. But #pragma GCC diagnostic tend
to be onerous. A better solution would be to have an attribute.
To that end, this patch adds a new attribute, [[gnu::no_dangling]].
This attribute takes an optional bool argument to support cases like:
template <typename T>
struct [[gnu::no_dangling(std::is_reference_v<T>)]] S {
// ...
};
PR c++/110358
PR c++/109642
gcc/cp/ChangeLog:
* call.cc (no_dangling_p): New.
(reference_like_class_p): Use it.
(do_warn_dangling_reference): Use it. Don't warn when the function
or its enclosing class has attribute gnu::no_dangling.
* tree.cc (cxx_gnu_attributes): Add gnu::no_dangling.
(handle_no_dangling_attribute): New.
gcc/ChangeLog:
* doc/extend.texi: Document gnu::no_dangling.
* doc/invoke.texi: Mention that gnu::no_dangling disables
-Wdangling-reference.
gcc/testsuite/ChangeLog:
* g++.dg/ext/attr-no-dangling1.C: New test.
* g++.dg/ext/attr-no-dangling2.C: New test.
* g++.dg/ext/attr-no-dangling3.C: New test.
* g++.dg/ext/attr-no-dangling4.C: New test.
* g++.dg/ext/attr-no-dangling5.C: New test.
* g++.dg/ext/attr-no-dangling6.C: New test.
* g++.dg/ext/attr-no-dangling7.C: New test.
* g++.dg/ext/attr-no-dangling8.C: New test.
* g++.dg/ext/attr-no-dangling9.C: New test.
|
|
In r12-6773-g09845ad7569bac we gave CTAD placeholders a level of 0 and
ensured we never replaced them via tsubst. It turns out that autos
representing an explicit cast need the same treatment and for the same
reason: such autos appear in an expression context and so their level
gets easily messed up after partial substitution, leading to premature
replacement via an incidental tsubst instead of via do_auto_deduction.
This patch fixes this by extending the r12-6773 approach to auto(x).
PR c++/110025
PR c++/114138
gcc/cp/ChangeLog:
* cp-tree.h (make_cast_auto): Declare.
* parser.cc (cp_parser_functional_cast): If the type is an auto,
replace it with a level-less one via make_cast_auto.
* pt.cc (find_parameter_packs_r): Don't treat level-less auto
as a type parameter pack.
(tsubst) <case TEMPLATE_TYPE_PARM>: Generalize CTAD placeholder
auto handling to all level-less autos.
(make_cast_auto): Define.
(do_auto_deduction): Handle replacement of a level-less auto.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/auto-fncast16.C: New test.
* g++.dg/cpp23/auto-fncast17.C: New test.
* g++.dg/cpp23/auto-fncast18.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
[PR92687]
finish_decltype_type uses DECL_HAS_VALUE_EXPR_P (expr) check for
DECL_DECOMPOSITION_P (expr) to determine if it is
array/struct/vector/complex etc. subobject proxy case vs. structured
binding using std::tuple_{size,element}.
For non-templates or when templates are already instantiated, that works
correctly, finalized DECL_DECOMPOSITION_P non-base vars indeed have
DECL_VALUE_EXPR in the former case and don't have it in the latter.
It works fine for dependent structured bindings as well, cp_finish_decomp in
that case creates DECLTYPE_TYPE tree and defers the handling until
instantiation.
As the testcase shows, this doesn't work for the non-dependent structured
binding case in templates, because DECL_HAS_VALUE_EXPR_P is set in that case
always; cp_finish_decomp ends with:
if (processing_template_decl)
{
for (unsigned int i = 0; i < count; i++)
if (!DECL_HAS_VALUE_EXPR_P (v[i]))
{
tree a = build_nt (ARRAY_REF, decl, size_int (i),
NULL_TREE, NULL_TREE);
SET_DECL_VALUE_EXPR (v[i], a);
DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
}
}
and those artificial ARRAY_REFs are used in various places during
instantiation to find out what base the DECL_DECOMPOSITION_P VAR_DECLs
have and their positions.
The following patch fixes that by changing lookup_decomp_type, such that
it doesn't ICE when called on a DECL_DECOMPOSITION_P var which isn't in a
hash table, but returns NULL_TREE in that case, and for processing_template_decl
asserts DECL_HAS_VALUE_EXPR_P is non-NULL and just calls lookup_decomp_type.
If it returns non-NULL, it is a structured binding using tuple and its result
is returned, otherwise it falls through to returning unlowered_expr_type (expr)
because it is an array, structure etc. subobject proxy.
For !processing_template_decl it keeps doing what it did before,
DECL_HAS_VALUE_EXPR_P meaning it is an array/structure etc. subobject proxy,
otherwise the tuple case.
2024-03-01 Jakub Jelinek <jakub@redhat.com>
PR c++/92687
* decl.cc (lookup_decomp_type): Return NULL_TREE if decomp_type_table
doesn't have entry for V.
* semantics.cc (finish_decltype_type): If ptds.saved, assert
DECL_HAS_VALUE_EXPR_P is true and decide on tuple vs. non-tuple based
on if lookup_decomp_type is NULL or not.
* g++.dg/cpp1z/decomp59.C: New test.
|
|
|
|
This PR asks that our -Wuninitialized for mem-initializers does
not warn when binding a reference to an uninitialized data member.
We already check !INDIRECT_TYPE_P in find_uninit_fields_r, but
that won't catch binding a parameter of a reference type to an
uninitialized field, as in:
struct S { S (int&); };
struct T {
T() : s(i) {}
S s;
int i;
};
This patch adds a new function to handle this case.
PR c++/113987
gcc/cp/ChangeLog:
* call.cc (conv_binds_to_reference_parm_p): New.
* cp-tree.h (conv_binds_to_reference_parm_p): Declare.
* init.cc (find_uninit_fields_r): Call it.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wuninitialized-15.C: Turn dg-warning into dg-bogus.
* g++.dg/warn/Wuninitialized-34.C: New test.
|
|
The fix for PR107398 weakened the restrictions that lambdas must belong
to namespace scope. However this was not sufficient: we also need to
allow lambdas attached to FIELD_DECLs, PARM_DECLs, and TYPE_DECLs.
For field decls we key the lambda to its class rather than the field
itself. Otherwise we can run into issues when deduplicating the lambda's
TYPE_DECL, because when loading its context we load the containing field
before we've deduplicated the keyed lambda, causing mismatches; by
keying to the class instead we defer checking keyed declarations until
deduplication has completed.
Additionally, by [basic.link] p15.2 a lambda defined anywhere in a
class-specifier should not be TU-local, which includes base-class
declarations, so ensure that lambdas declared there are keyed
appropriately as well.
Because this now requires 'DECL_MODULE_KEYED_DECLS_P' to be checked on a
fairly large number of different kinds of DECLs, and that in general
it's safe to just get 'false' as a result of a check on an unexpected
DECL type, this patch also removes the tree checking from the accessor.
Finally, to handle deduplicating templated lambda fields, we need to
ensure that we can determine that two lambdas from different field decls
match, so we ensure that we also deduplicate LAMBDA_EXPRs on stream in.
PR c++/111710
gcc/cp/ChangeLog:
* cp-tree.h (DECL_MODULE_KEYED_DECLS_P): Remove tree checking.
(struct lang_decl_base): Update comments and fix whitespace.
* module.cc (trees_out::lang_decl_bools): Always write
module_keyed_decls_p flag...
(trees_in::lang_decl_bools): ...and always read it.
(trees_out::decl_value): Handle all kinds of keyed decls.
(trees_in::decl_value): Likewise.
(trees_in::tree_value): Deduplicate LAMBDA_EXPRs.
(maybe_key_decl): Also support lambdas attached to fields,
parameters, and types. Key lambdas attached to fields to their
class.
(trees_out::get_merge_kind): Likewise.
(trees_out::key_mergeable): Likewise.
(trees_in::key_mergeable): Support keyed decls in a TYPE_DECL
container.
* parser.cc (cp_parser_class_head): Start a lambda scope when
parsing base classes.
gcc/testsuite/ChangeLog:
* g++.dg/modules/lambda-7.h: New test.
* g++.dg/modules/lambda-7_a.H: New test.
* g++.dg/modules/lambda-7_b.C: New test.
* g++.dg/modules/lambda-7_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Patrick Palka <ppalka@redhat.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
|
|
implicit instantation [PR113976]
Already previously instantiated const variable templates had
cp_apply_type_quals_to_decl called when they were instantiated,
but if they need runtime initialization, their TREE_READONLY flag
has been subsequently cleared.
Explicit variable template instantiation calls grokdeclarator which
calls cp_apply_type_quals_to_decl on them again, setting TREE_READONLY
flag again, but nothing clears it afterwards, so we emit such
instantiations into rodata sections and segfault when the dynamic
initialization attempts to initialize them.
The following patch fixes that by not calling cp_apply_type_quals_to_decl
on already instantiated variable declarations.
2024-02-28 Jakub Jelinek <jakub@redhat.com>
Patrick Palka <ppalka@redhat.com>
PR c++/113976
* decl.cc (grokdeclarator): Don't call cp_apply_type_quals_to_decl
on DECL_TEMPLATE_INSTANTIATED VAR_DECLs.
* g++.dg/cpp1y/var-templ87.C: New test.
|
|
This is a (partial) reversion of r14-8987-gdd9d14f7d53 to return to
eagerly emitting inline variables to the middle-end when they are
declared. 'import_export_decl' will still continue to accept them, as
allowing this is a pure extension and doesn't seem to cause issues with
modules, but otherwise deferring the emission of inline variables
appears to cause issues on some targets and prevents some code using
inline variable templates from correctly linking.
There might be a more targetted way to support this, but due to the
complexity of handling linkage and emission I'd prefer to wait till
GCC 15 to explore our options.
PR c++/113970
PR c++/114013
gcc/cp/ChangeLog:
* decl.cc (make_rtl_for_nonlocal_decl): Don't defer inline
variables.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/inline-var10.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
|
|
|
|
arches (aka arm32) [PR113083]
When targetm.cxx.cdtor_returns_this () (aka on arm32 TARGET_AAPCS_BASED)
constructor is supposed to return this pointer, but when we cp_fold such
a call, we don't take that into account and just INIT_EXPR the object,
so we can later ICE during gimplification, because the expression doesn't
have the right type.
2024-02-23 Jakub Jelinek <jakub@redhat.com>
PR c++/113083
* cp-gimplify.cc (cp_fold): For targetm.cxx.cdtor_returns_this ()
wrap r into a COMPOUND_EXPR and return folded CALL_EXPR_ARG (x, 0).
* g++.dg/cpp0x/constexpr-113083.C: New test.
|
|
|
|
When partially substituting a requires-expr, we don't want to perform
any additional checks beyond the substitution itself so as to minimize
checking requirements out of order. So don't check the return-type-req
of a compound-requirement during partial substitution. And don't check
the noexcept condition either since we can't do that on templated trees.
PR c++/113966
gcc/cp/ChangeLog:
* constraint.cc (tsubst_compound_requirement): Don't check
the noexcept condition or the return-type-requirement when
partially substituting.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-friend17.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
|
|
Here we find ourselves in maybe_check_overriding_exception_spec in
a template context where we can't instantiate a dependent noexcept.
That's OK, but we have to defer the checking otherwise we give wrong
errors.
PR c++/113158
gcc/cp/ChangeLog:
* search.cc (maybe_check_overriding_exception_spec): Defer checking
when a noexcept couldn't be instantiated & evaluated to false/true.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept83.C: New test.
|
|
|
|
I noticed we don't implement the "unless the overriding function is
defined as deleted" wording added to [except.spec] via CWG 1351.
DR 1351
gcc/cp/ChangeLog:
* search.cc (maybe_check_overriding_exception_spec): Don't error about
a looser exception specification if the overrider is deleted.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept82.C: New test.
|
|
Here we have
template<class T>
auto is_throwable(T t) -> decltype(throw t, true) { ... }
where we didn't properly mark 't' as IMPLICIT_RVALUE_P, which caused
the wrong overload to have been chosen. Jason figured out it's because
we don't correctly implement [expr.prim.id.unqual]#4.2, which post-P2266
says that an id-expression is move-eligible if
"the id-expression (possibly parenthesized) is the operand of
a throw-expression, and names an implicitly movable entity that belongs
to a scope that does not contain the compound-statement of the innermost
lambda-expression, try-block, or function-try-block (if any) whose
compound-statement or ctor-initializer contains the throw-expression."
I worked out that it's trying to say that given
struct X {
X();
X(const X&);
X(X&&) = delete;
};
the following should fail: the scope of the throw is an sk_try, and it's
also x's scope S, and S "does not contain the compound-statement of the
*try-block" so x is move-eligible, so we move, so we fail.
void f ()
try {
X x;
throw x; // use of deleted function
} catch (...) {
}
Whereas here:
void g (X x)
try {
throw x;
} catch (...) {
}
the throw is again in an sk_try, but x's scope is an sk_function_parms
which *does* contain the {} of the *try-block, so x is not move-eligible,
so we don't move, so we use X(const X&), and the code is fine.
The current code also doesn't seem to handle
void h (X x) {
void z (decltype(throw x, true));
}
where there's no enclosing lambda or sk_try so we should move.
I'm not doing anything about lambdas because we shouldn't reach the
code at the end of the function: the DECL_HAS_VALUE_EXPR_P check
shouldn't let us go further.
PR c++/113789
PR c++/113853
gcc/cp/ChangeLog:
* typeck.cc (treat_lvalue_as_rvalue_p): Update code to better
reflect [expr.prim.id.unqual]#4.2.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/sfinae69.C: Remove dg-bogus.
* g++.dg/cpp0x/sfinae70.C: New test.
* g++.dg/cpp0x/sfinae71.C: New test.
* g++.dg/cpp0x/sfinae72.C: New test.
* g++.dg/cpp2a/implicit-move4.C: New test.
|
|
For template parameters, the optional this specifier is in the grammar
template-parameter-list -> template-parameter -> parameter-declaration,
just [dcl.fct/6] says that it is only valid in parameter-list of certain
functions. So, unlike the case of decl-specifier-seq used in non-terminals
other than parameter-declaration, I think it is better not to fix this
by
cp_parser_decl_specifier_seq (parser,
- flags | CP_PARSER_FLAGS_PARAMETER,
+ flags | (template_parameter_p ? 0
+ : CP_PARSER_FLAGS_PARAMETER),
&decl_specifiers,
&declares_class_or_enum);
which would be pretending it isn't in the grammar, but by diagnosing it
separately, which is what the following patch does.
2024-02-16 Jakub Jelinek <jakub@redhat.com>
PR c++/113929
* parser.cc (cp_parser_parameter_declaration): Diagnose this specifier
on template parameter declaration.
* g++.dg/parse/pr113929.C: New test.
|
|
gcc/cp/ChangeLog:
* module.cc (trees_out::core_bools): Stream TREE_UNAVAILABLE.
(trees_in::core_bools): Likewise.
(trees_out::core_vals): Stream LAMBDA_EXPR_REGEN_INFO.
(trees_in::core_vals): Likewise.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
|
|
Inline variables are vague-linkage, and may or may not need to be
emitted in any TU that they are part of, similarly to e.g. template
instantiations.
Currently 'import_export_decl' assumes that inline variables have
already been emitted when it comes to end-of-TU processing, and so
crashes when importing non-trivially-initialised variables from a
module, as they have not yet been finalised.
This patch fixes this by ensuring that inline variables are always
deferred till end-of-TU processing, unifying the behaviour for module
and non-module code.
PR c++/113708
gcc/cp/ChangeLog:
* decl.cc (make_rtl_for_nonlocal_decl): Defer inline variables.
* decl2.cc (import_export_decl): Support inline variables.
gcc/testsuite/ChangeLog:
* g++.dg/debug/dwarf2/inline-var-1.C: Reference 'a' to ensure it
is emitted.
* g++.dg/debug/dwarf2/inline-var-3.C: Likewise.
* g++.dg/modules/init-7_a.H: New test.
* g++.dg/modules/init-7_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
|
|
In the second testcase below, during ahead of time checking of the
non-dependent new-expr we synthesize B's copy ctor, which we expect to
get defined as deleted since A's copy ctor is inaccessible. But during
access checking thereof, enforce_access incorrectly decides to defer it
since we're in a template context according to current_template_parms
(before r14-557 it checked processing_template_decl which got cleared
from implicitly_declare_fn), which leads to the access check leaking out
to the template context that triggered the synthesization, and B's copy
ctor getting declared as non-deleted.
This patch fixes this by using maybe_push_to_top_level to clear the
context (including current_template_parms) before proceeding with the
synthesization. We could do this from implicitly_declare_fn, but it's
better to do it more generally from synthesized_method_walk for sake of
its other callers.
This turns out to fix PR113332 as well: there the lambda context
triggering synthesization was causing maybe_dummy_object to misbehave,
but now synthesization is sufficiently context-independent.
PR c++/113908
PR c++/113332
gcc/cp/ChangeLog:
* method.cc (synthesized_method_walk): Use maybe_push_to_top_level.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/lambda/lambda-nsdmi11.C: New test.
* g++.dg/template/non-dependent31.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
This ensures that with modules enabled, redeclaring an enum in the wrong
module or with the wrong underlying type no longer ICEs.
The patch also rearranges the order of the checks a little because I
think it's probably more important to note that you can't redeclare the
enum all before complaining about mismatched underlying types etc.
As a drive by this patch also adds some missing diagnostic groups, and
rewords the module redeclaration error message to more closely match the
wording used in other places this check is done.
PR c++/99573
gcc/cp/ChangeLog:
* decl.cc (start_enum): Reorder check for redeclaring in module.
Add missing auto_diagnostic_groups.
gcc/testsuite/ChangeLog:
* g++.dg/modules/enum-12.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
|
|
A minimal fix to quash an extra ; warning. I have a more complete
patch for GCC 15.
DR 1693
PR c++/113760
gcc/cp/ChangeLog:
* parser.cc (cp_parser_member_declaration): Only pedwarn about an extra
semicolon in C++98.
gcc/testsuite/ChangeLog:
* g++.dg/semicolon-fixits.C: Run in C++98 only.
* g++.dg/warn/pedantic2.C: Adjust dg-warning.
* g++.old-deja/g++.jason/parse11.C: Adjust dg-error.
* g++.dg/DRs/dr1693-1.C: New test.
* g++.dg/DRs/dr1693-2.C: New test.
|
