This is the mail archive of the
mailing list for the GCC project.
Re: ObjC++: fix testcase failures on Darwin
- From: IainS <developer at sandoe-acoustics dot co dot uk>
- To: Mike Stump <mikestump at comcast dot net>
- Cc: Nicola Pero <nicola dot pero at meta-innovation dot com>, "gcc-patches at gnu dot org" <gcc-patches at gnu dot org>
- Date: Mon, 29 Nov 2010 21:19:36 +0000
- Subject: Re: ObjC++: fix testcase failures on Darwin
- References: <firstname.lastname@example.org> <66630843-C316-41AD-B8D2-6EC2312C4F88@comcast.net>
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
using an attribute ("objc_volatilized") but the problem is that
newer GCCs are
smarted and consider attributes when building variants of types.
additional attribute actually confuses the type system (for
example, if you start
with a non-volatilized 'int' type, and build the artificially
and then you try to get a non-volatile type variant using
you don't get the original type but a new 'int' type which
preserves your new
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
canonical type. The C++ frontend detects this inconsistency and
So, in the end I created a new TYPE_ARTIFICIALLY_VOLATILIZED() flag
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
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
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
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
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
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-
(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?