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