This is the mail archive of the
mailing list for the GCC project.
Re: patch to fix tentative struct type collision
- From: Ian Lance Taylor <iant at google dot com>
- To: Fariborz Jahanian <fjahanian at apple dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: 13 Dec 2006 08:50:50 -0800
- Subject: Re: patch to fix tentative struct type collision
- References: <44A2F708-3163-46FB-8761-A1091A0D4C86@apple.com>
Fariborz Jahanian <firstname.lastname@example.org> 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
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.