This is the mail archive of the 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: patch to fix tentative struct type collision

On Dec 13, 2006, at 8:50 AM, Ian Lance Taylor wrote:

Fariborz Jahanian <> 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


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