patch to fix tentative struct type collision

[Ian Lance Taylor]

Fariborz Jahanian <fjahanian@apple.com> writes:

> When searching for a tentative struct type in type_hash_eq, if it
> collides with another similar type, currently type_hash_eq says it is
> a match since both types' TYPE_FIELDS is NULL. This is incorrect and
> causes bad things to happen as it matches "struct foo' with "struct
> bar", for example. I ran into this problem when made a call to
> build_type_attribute_variant to create a new duplicate type with new
> attributes. Attach patch, which is dejagnu and bootstrap tested on
> apple-x86-darwin, fixes the problem.

To me this looks like a middle-end type system problem.  My
understanding is that in C two structs are compatible if they have the
same fields.  In C++ they are compatible if they have the same name.
type_hash_eq currently uses the C semantics.

I think that frontends, other than perhaps the C frontend, simply can
not currently call build_type_attribute_variant with a RECORD_TYPE
from the frontend.  The middle-end type system is too imprecise to
support that.  As far as I can see, the C++ frontend never does that.

Note that when the code in c-common.c, which is also used by C++,
wants to set an attribute on a structure, it calls
build_variant_type_copy.

In any case, the patch as it stands looks clearly incorrect to me.  It
does not make sense to only check TYPE_NAME when there are no fields.
If we check it at all, we need to check it in all cases.  And the
patch would need a test case.

Ian