c++: Fix tree_contains_struct for TRAIT_EXPR

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 will change to be 64 bytes, as is under discussion, 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 will end 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.

gcc/cp/ChangeLog:

	* cp-objcp-common.cc (cp_common_init_ts): Change TRAIT_EXPR from
	TS_EXP to TS_TYPED.
This commit is contained in:
Lewis Hyatt 2024-11-02 21:59:24 -04:00 committed by Lewis Hyatt
parent 4a7bb1dade
commit d7ef7d1258
No known key found for this signature in database

View file

@ -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);