This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Fix ObjC @"string" machinery
- From: Andrew Pinski <pinskia at physics dot uc dot edu>
- To: Ziemowit Laski <zlaski at apple dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 21 Jun 2005 21:11:07 -0400
- Subject: Re: PATCH: Fix ObjC @"string" machinery
- References: <f077df190aaed954b836c8456ae41477@apple.com>
On Jun 21, 2005, at 9:05 PM, Ziemowit Laski wrote:
At present, gcc-4.0 complains about invalid class layout if
NSConstantString,
NXConstantString or the class specified via
-fconstant-string-class=... has
a non-trivial inheritance structure (see the 4 test cases attached).
This
used to work before the recent ObjC comptypes rewrite went in :-(;
now, it
is no longer permissible to check TYPE_FIELDS() to get all the ivars
for
a given class implementation, since TYPE_BINFO (and other goodies
pleasing
to the middle- and back-ends) is being used.
To work around this, I synthesize an internal string type,
called__builtin_ObjCString,
construct const objects of that type, and then cast to
NSConstantString/NXConstantString/
whatever as appropriate. Note that this has the side-effect of
streamlining the section
selection logic in darwin.c a bit.
Thoughts? I will wait until tomorrow morning (Pacific time) before
committing,
should people have comments.
Yes this breaks non C based languages (Fortran and Java and Ada) by the
use
of flag_next_runtime.
-- Pinski