On 11/3/24 5:22 PM, Lewis Hyatt wrote:
CODE_CONTAINS_STRUCT () currently reports that a TRAIT_EXPR contains a
TS_EXP struct, but it does not actually start with a TS_EXP as an initial
sequence. In modules.cc, when we stream out a tree, we explicitly check for the
TS_EXP case and call note_location(t->exp.locus) if so. Currently, this
actually queries the tree_common::chain field of a tree_trait_expr, which
seems not to be used, returning 0, which is interpreted as UNKNOWN_LOCATION
and does no harm.
If location_t has been configured to be 64 bytes, then on 32-bit platforms
(well those, such as sparc, on which uint64_t has higher alignment requirement
than a pointer), reading t->exp.locus ends up reading a different field
(tree_trait_expr::type1) due to padding offsets. That field is not generally
0, and the resulting bogus location_t is sufficiently problematic to cause
an ICE in the line_map code. Pretty much any modules testcase displays the
issue, such as partial-2_a.C.
Resolve by initializing tree_contains_struct with the correct value for
TRAIT_EXPR, namely TS_TYPED.
OK.
gcc/cp/ChangeLog:
* cp-objcp-common.cc (cp_common_init_ts): Change TRAIT_EXPR from
TS_EXP to TS_TYPED.
---
gcc/cp/cp-objcp-common.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/cp/cp-objcp-common.cc b/gcc/cp/cp-objcp-common.cc
index 7a0636f1653..1e43db31db8 100644
--- a/gcc/cp/cp-objcp-common.cc
+++ b/gcc/cp/cp-objcp-common.cc
@@ -617,6 +617,7 @@ cp_common_init_ts (void)
MARK_TS_TYPED (PTRMEM_CST);
MARK_TS_TYPED (LAMBDA_EXPR);
MARK_TS_TYPED (TYPE_ARGUMENT_PACK);
+ MARK_TS_TYPED (TRAIT_EXPR);
/* Random new trees. */
MARK_TS_COMMON (BASELINK);
@@ -684,7 +685,6 @@ cp_common_init_ts (void)
MARK_TS_EXP (TAG_DEFN);
MARK_TS_EXP (TEMPLATE_ID_EXPR);
MARK_TS_EXP (THROW_EXPR);
- MARK_TS_EXP (TRAIT_EXPR);
MARK_TS_EXP (TYPEID_EXPR);
MARK_TS_EXP (TYPE_EXPR);
MARK_TS_EXP (UNARY_PLUS_EXPR);
