Georg-Johann Lay <[email protected]> writes: >> But the rest of the compiler would probably need similar changes, as, >> AFAICT, it all assumes that TREE_ADDR_SPACE (array) is set to >> TREE_ADDR_SPACE (TREE_TYPE (array)) prior to using it. >> Alternatively, of course, we could make such a EXPR_OR_DECL_ADDR_SPACE >> and replace all (applicable) usages of TYPE_ADDR_SPACE with it. >> I think it'd be semantically sound to make GENERIC semantics match C++ >> when dealing with address spaces on array types (i.e. define that the >> the address space of an array type is the address space of the element >> type; nothing else really makes sense after all), so it may be best to >> make TYPE_ADDR_SPACE strip arrays. > > I am not sure if that's a good idea. For example the outcome of > strip_array_types() might be error_mark_node. > > Moreover, while convenient in many places, it would be confusing.
It's not just convenience, it's also semantically more sound, IMO. Such a change would make it impossible to have the (nonsensical) scenario where an array has its elements in some other address space (which is the confusion that lead to the bug you found). The outcome of strip_array_types() can be error_mark_node iff the array passed into it is an array of error types (or, of course, if the error mark was passed into it). But, if it is such an array, then we need to invent an address space to place on the array type anyway (in build_min_array_type). Ergo, it seems to me equivalent to treat that case as if it were the generic address space anyway, in the TYPE_ADDR_SPACE accessor. Indeed, ISTM that at least varasm.cc already deals with the error mark in that way, and other places probably do too. -- Arsen Arsenović
signature.asc
Description: PGP signature
