This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PR 79905] ICE with vector_type


On 04/04/2017 04:27 AM, Richard Biener wrote:
On Mon, Apr 3, 2017 at 9:03 PM, Nathan Sidwell <nathan@acm.org> wrote:

However, as you can see there's already a get-out for COMPLEX_TYPE, and I
think the same is needed for VECTOR_TYPE.

Hmm, but that is essentially a hack given that build_complex_type does things
it shouldn't (assign a name to the type).

Oh, didn't know that.

Both set_underlying_type and rs6000 set the builtin vector type's TYPE_NAME,
and so one constructed via applying __attribute__((vector_size(16))) will
never match.   And it should.

why?  They only need to share the canonical type not the type node itself
(unless their name is the same, of course).

Correct, that's what I meant. the canonical type equal function must match a just-consed vector with the already-hashed builtin.

Now -- that name comparing is somewhat odd.  We hash type "variants"
with different names the same (so setting the name after inserting sth into
the hash is allowed, but it will overwrite the old entry so any unnamed uses
up to now get a type with a name...).  I guess we'd be better off leaving
only unnamed types in the hash and building a type variant whenever we
add a name to such type.

Right, the name matching surprised me, and my first attempt was to remove it. but that breaks wchar_t. wchar_t is the same representation as int (pedantically, some integral type), but is a distinct type (in C++ at least, I don't think C cares). The canonical type system records language-level distinctness, not representation distinctness.

The difference between wchar_t and vector types is the only way to get a type the same as wchar_t is to use 'wchar_t' (so we have to start with a type at least as canonical as what we want). Whereas vector types are constructed via applying attributes to some underlying scalar type (so we have to go find the canonical type).

It would therefore seem that this code in set_underlying_type (c-common.c) is wrong:
  if (DECL_IS_BUILTIN (x) && TREE_CODE (TREE_TYPE (x)) != ARRAY_TYPE)
    {
      if (TYPE_NAME (TREE_TYPE (x)) == 0)
	TYPE_NAME (TREE_TYPE (x)) = x;
    }

And this rs6000.c code is totally bogus:
tdecl = add_builtin_type ("__vector unsigned int", unsigned_V4SI_type_node);
  TYPE_NAME (unsigned_V4SI_type_node) = tdecl; <-- this line

(note that at this point, add_builtin_type has already set the TYPE_NAME via set_underlying type)

For C++'s creation of the wchar_t node, we'd need to special case setting the node's name in some way?

[char16_t and char32_t have the same distinctness property as wchar_t. I think that's the complete set]

nathan

--
Nathan Sidwell


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]