On Mon, Apr 3, 2017 at 9:03 PM, Nathan Sidwell <nat...@acm.org> wrote: > Bill, > can you give this patch a spin please? I've smoke tested it on a ppc64le > x-compiler, but don't have one to run executables. regression testing on an > x86_64-linux system is ok. > > The DEPENDENT_TYPE_VALID_P thing is a red herring. > > It is the canonical type table's equal function considering most types with > different TYPE_NAMEs to be different. Now, you might think that only > applies to things like RECORD_TYPE, but no, wchar_t is different from plain > int, for example. > > 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). make_vector_type doesn't do that so it shouldn't get such special-handing. > 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). 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. Richard. > nathan > -- > Nathan Sidwell >
