On 1/15/25 9:43 AM, Jason Merrill wrote:
On 11/25/24 4:46 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
In a template, for
union {
union {
T d;
};
};
build_anon_union_vars crates a malformed COMPONENT_REF: we have no
DECL_NAME for the nested anon union so we create something like
"object.".
Most of the front end doesn't seem to care, but if such a tree gets to
potential_constant_expression, it can cause a crash.
I suppose we can use any name for the COMPONENT_REF's member.
tsubst_stmt
should build up a proper one in:
if (VAR_P (decl) && !DECL_NAME (decl)
&& ANON_AGGR_TYPE_P (TREE_TYPE (decl)))
/* Anonymous aggregates are a special case. */
finish_anon_union (decl);
PR c++/117153
gcc/cp/ChangeLog:
* decl2.cc (build_anon_union_vars): If DECL_NAME is empty, use
an anonymous name for the second operand of a COMPONENT_REF.
gcc/testsuite/ChangeLog:
* g++.dg/other/anon-union6.C: New test.
* g++.dg/other/anon-union7.C: New test.
---
gcc/cp/decl2.cc | 5 ++++-
gcc/testsuite/g++.dg/other/anon-union6.C | 13 +++++++++++++
gcc/testsuite/g++.dg/other/anon-union7.C | 16 ++++++++++++++++
3 files changed, 33 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/other/anon-union6.C
create mode 100644 gcc/testsuite/g++.dg/other/anon-union7.C
diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index bc3a9d0e922..1383cbb660c 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -1959,7 +1959,10 @@ build_anon_union_vars (tree type, tree object)
if (processing_template_decl)
ref = build_min_nt_loc (UNKNOWN_LOCATION, COMPONENT_REF, object,
- DECL_NAME (field), NULL_TREE);
+ (DECL_NAME (field)
+ ? DECL_NAME (field)
+ : make_anon_name ()),
+ NULL_TREE);
Why don't we use the field directly instead of its name, even for named
fields?
I guess instantiation_dependent_r has a clue:
/* In a template, finish_class_member_access_expr creates a
COMPONENT_REF with an IDENTIFIER_NODE for op1 even if it isn't
type-dependent, so that we can check access control at
instantiation time (PR 42277). See also Core issue 1273. */
but I don't think we need to care about that in build_anon_union_vars.
Jason
