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: Fix ObjC @"string" machinery

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

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