This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: patch to fix tentative struct type collision
On Dec 13, 2006, at 8:50 AM, Ian Lance Taylor wrote:
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.
In this case, same fields are NULL. Is 'struct Foo *' compatible with
'struct Bar *' in C?
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.
It cannot because of shortcoming in type_hash_eq. Maybe we should fix
type_hash_eq instead of disallowing using build_type_attribute_variant.
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.
Thanks for the hint. I will try this.
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
Checking for TYPE_NAME is one case. What are the other cases?
patch would need a test case.
Sorry, I cannot give a test case because it involves many new objc2
features which are not yet pushed into 4.2 branch. I think we should
fix type_hash_eq to support all types regardless of how it is used;
JMO of course.
- Thanks, Fariborz
Ian