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: ObjC++: fix testcase failures on Darwin

On 29 Nov 2010, at 21:00, Mike Stump wrote:

On Nov 28, 2010, at 6:28 PM, Nicola Pero wrote:
This patch fixes the 5 @try/@catch ObjC++ testsuite failures on Darwin (Apple) with the NeXT runtime.

Hum... I don't think this is going to work.

The code we "inherited" from Apple flagged these artificially volatilized types
using an attribute ("objc_volatilized") but the problem is that newer GCCs are
smarted and consider attributes when building variants of types. So the
additional attribute actually confuses the type system (for example, if you start
with a non-volatilized 'int' type, and build the artificially volatilized variant,
and then you try to get a non-volatile type variant using build_qualified_type(),
you don't get the original type but a new 'int' type which preserves your new
objc_volatilized attribute.

Ah, but this sounds like a one line fix to remove the attribute in that one case. Would this work? Downsides?

This new 'int' is identical to the normal 'int'
though, except for the 'objc_volatilized' attribute, but has a different
canonical type. The C++ frontend detects this inconsistency and aborts).

So, in the end I created a new TYPE_ARTIFICIALLY_VOLATILIZED() flag that can
be used for types (I used the base.side_effects flag which is unused for types
in C/ObjC/C++/ObjC++), and used it to mark our artificially volatilized types.

The problem is, that bit isn't ours to play with, and, no existing code plays with that bit or understands it and we don't really want to propagate such system specific details into such an important bit. Whereas, playing with attributes isn't unreasonable and it just for such system specific playing.

Then the type system works again and everything seems to work with the next
runtime, with the exception of two warnings in try-catch-12.m. These occur when
a real 'volatile' variable is encountered in the same context as artificially
volatilized ones, and if certain conditions are met the two types can get confused
and some warnings for the real volatile variable may not be produced.

Yes, these are the problems that we wanted to avoid by using the attribute.

To fix this, either we think of a completely different way of doing everything, or we
may need to push some (or a lot of) awareness of TYPE_ARTIFICIALLY_VOLATILIZED()
into tree.c.

Well, we want to avoid pushing just as much as we possibly can into tree.c. Really, the volatile is about codegen, and conceptually, is only for codegen.

So, let's talk about this some more... I'm hoping that there is a more tactical solution. I'm expecting that we could put in a call to objc_non_volatilized_type in a spot or two and be done with it.

Is there any way we can shift the code-gen to the lang-specific- gimpifier?
(I fear we will need yet another code-gen for m64 NeXT exceptions).

Ideally, we'd have only one parse pathway [on the basis that the language is common and we're only changing runtime]
and switch the code-gen on runtime...

too big a change I guess?

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