[Bug lto/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094

--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> 2011-12-06 09:11:56 UTC ---
(In reply to comment #13)
> (In reply to comment #12)
> > I guess, ideally, the ObjC meta-data should be re-created after LTO has done
> > its magic -- but that's def. not a stage 3 type job ...
> 
> Ideally from what point of view? Certainly not that of one where there is
> proper separation between front ends and the middle end. There are no language
> specific post optimization passes. From the point of view of the LTO front end,
> whatever the ObjC-family front ends have handed over is language independent.

... I do see the point about separation - and I wasn't intending to imply that
there was lang-specific optimization.
 (what I meant to say is that, if the meta-data are created for the optimized
code, then they are already - by definition - optimized themselves).

I would not propose a lang-specific ME pass ... however, I might propose a pass
that deals with one category of construct (which only happens to be generated
by one FE).   Surely we do this already - the ME just deals with constructs -
some of which are only ever generated by Fortran or Ada or C++ ?? 

 [[ probably displaying my considerable lack of knowledge about the ME here ]]

===

The metadata are really a property of the target runtime (thus, they change
depending on the target runtime, for the same ObjC source).

So, at the least, they are in a grey area.  (IMO) The front-end would ideally
be completely target-runtime agnostic - at least until lowering to gimple (the
method calls are constructed differently, for example).

so, for the same ME data, one should - in principle - be able to generate the
correct metadata for the target  ...

... however, clearly, this does not belong in the back end either (since that
would imply duplication that is not needed) ... :-(

-- so perhaps we are left with needing to communicate something between the two
... in the same manner that we "tell" the back end how to express things that
have alignment or visibility attributes attached to them in the FE ... 

just musing about possible solutions .. nothing that feels particularly "Right"
as it stands ... .

> But those two L_OBJC_ImageInfo variables have a number appended. Is that
> supposed to be so? Or is this LTO declaration merging at work and maybe you
> want to avoid that?
> (Maybe I'm talking completely non-sense, but something like that came up for
> PR47259 also...)

I think that LTO is behaving entirely correctly now (the original example in
the bug has been fixed).

N input files containing a local variable (even if it has the same name in
each) should produce N instances of that in the output - which is what is
happening.

I would guess have no way to mark a variable as "local, but shared" because -
probably outside of this case there is no ld that could make sense of it. 

 I don't know if it will currently break the NeXT ObjC runtime if we re-specify
the section as coalesced and mark the vars as DECL_ONE_ONLY.. but I suspect it
will break at some point.