Re: ObjC++: fix testcase failures on Darwin

[IainS <developer at sandoe-acoustics dot co dot uk>]

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?
Iain