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

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

[howarth at nitro dot med.uc.edu]

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

           Summary: ld: warning: section has unexpectedly large size
                    errors in objc/obj-c++ lto
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: howarth@nitro.med.uc.edu


A large number of new failures occur in the objc/obj-c++ testsuite when built
under Xcode 4.0 on x86_64-apple-darwin10. These failures are all of the form...

Executing on host: /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/ objc_lto_trivial-1_0.o
 -O0 -flto -flto-partition=none -fnext-runtime  
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/i386/libobjc/.libs
 
-L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/i386/libobjc/.libs
  -lobjc     -m32 -o objc-dg-lto-trivial-1-21    (timeout = 300)
ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in
/var/tmp//ccMlEsXS.lto.o^M
Undefined symbols for architecture i386:^M
  ".objc_class_name_myRootObject", referenced from:^M
      pointer-to-literal-objc-class-name in ccMlEsXS.lto.o^M
      pointer-to-literal-objc-class-name in ccMlEsXS.lto.o^M
ld: symbol(s) not found for architecture i386^M
collect2: ld returned 1 exit status^M
compiler exited with status 1
output is:
ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in
/var/tmp//ccMlEsXS.lto.o^M
Undefined symbols for architecture i386:^M
  ".objc_class_name_myRootObject", referenced from:^M
      pointer-to-literal-objc-class-name in ccMlEsXS.lto.o^M
      pointer-to-literal-objc-class-name in ccMlEsXS.lto.o^M
ld: symbol(s) not found for architecture i386^M
collect2: ld returned 1 exit status^M

FAIL: objc.dg/lto/trivial-1 objc_lto_trivial-1_0.o-objc_lto_trivial-1_0.o link,
-O0 -flto -flto-partition=none -fnext-runtime

The ld warning for "unexpectedly large size" is always associated with an
undefined symbol for .objc_class_name_myRootObject.

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

[howarth at nitro dot med.uc.edu]

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

--- Comment #1 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-03-12 17:32:18 UTC ---
Using built-in specs.
COLLECT_GCC=gcc-4
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.7.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.7.0
Configured with: ../gcc-4.6-20110311/configure --prefix=/sw
--prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.6 --enable-checking=yes --enable-cloog-backend=isl
Thread model: posix
gcc version 4.6.0 20110312 (experimental) (GCC)

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

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011.03.12 17:48:56
     Ever Confirmed|0                           |1

--- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-12 17:48:56 UTC ---

(a) the first is because LTO has produced two image_info instances with
different mangled names ...

     e.g. L_OBJC_ImageInfo.2044 / L_OBJC_ImageInfo.2048

     this is visible on darwin 9 (although it does not produce an error).

(b) the second needs more checking - the tests pass on darwin9 (and darwin10
with 3.2.5 - last time I tried)

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

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-12 18:34:51 UTC ---
(In reply to comment #2)

> (b) the second needs more checking - the tests pass on darwin9 (and darwin10
> with 3.2.5 - last time I tried)

it looks like the .lazy_reference to . objc_class_name_myRootObject is getting
dropped somewhere;
in this instance, because the code is self-contained, it works OK (when ld
doesn't barf).

... in other cases in the test-suite, the only external object is usually
"Object" which is in libobjc and therefore it also works.

I have an idea about getting rid of the TARGET_ASM method to make these
references and use a real variable to carry the information (just make it
zero-sized, and use that + a meta-data tag to emit the efficient asm).   I was
intending to make that a stage-1 investigation -- but perhaps it might warrant
trying sooner.

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

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-13 12:13:05 UTC ---
(In reply to comment #2)
> (a) the first is because LTO has produced two image_info instances with
> different mangled names ...
> 
>      e.g. L_OBJC_ImageInfo.2044 / L_OBJC_ImageInfo.2048
> 
>      this is visible on darwin 9 (although it does not produce an error).

This only applies when -flto is given together with the partitioning algorithm
= none.  
For 1to1 or default, the instances of L_OBJC_ImageInfo are correctly combined
into a single var.

I'm not sure whether this is expected behavior (c.f. PR43038) ?

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

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-14 09:40:07 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> 
> > (b) the second needs more checking - the tests pass on darwin9 (and darwin10
> > with 3.2.5 - last time I tried)
> 
> it looks like the .lazy_reference to . objc_class_name_myRootObject is getting
> dropped somewhere;
> in this instance, because the code is self-contained, it works OK (when ld
> doesn't barf).
> 
> ... in other cases in the test-suite, the only external object is usually
> "Object" which is in libobjc and therefore it also works.
> 
> I have an idea about getting rid of the TARGET_ASM method to make these
> references and use a real variable to carry the information (just make it
> zero-sized, and use that + a meta-data tag to emit the efficient asm).   I was
> intending to make that a stage-1 investigation -- but perhaps it might warrant
> trying sooner.

this is now PR48109 -- and a separate issue, please use PR48094 to track the
image_info issue.

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

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> 2011-11-13 19:49:04 UTC ---
could you please check the status of this with XCode 4. / Darwin11.

AFAICT, this (duplicate __image_info sections) appears to be resolved.. 

.. although the Undefined symbols for architecture 
.objc_class_name_myRootObject might well still be present.

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

[howarth at nitro dot med.uc.edu]

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

--- Comment #7 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-12-03 15:49:49 UTC ---
(In reply to comment #6)
> could you please check the status of this with XCode 4. / Darwin11.
> 
> AFAICT, this (duplicate __image_info sections) appears to be resolved.. 
> 
> .. although the Undefined symbols for architecture 
> .objc_class_name_myRootObject might well still be present.

Current gcc trunk now just shows warnings of the form...

ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in
/var/tmp//ccsj97TC.lto.o

in objc.log for Xcode 4.2.1 on Lion. The undefined
.objc_class_name_myRootObject symbols
are still present.

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

[iains at gcc dot gnu.org]

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

--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> 2011-12-03 18:30:44 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > could you please check the status of this with XCode 4. / Darwin11.

> Current gcc trunk now just shows warnings of the form...
> 
> ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in
> /var/tmp//ccsj97TC.lto.o

hmmm.. OK there's some difference between D10 and D11 then..

please could you produce and attach the asm (-fverbose-asm) for the test-case
using current trunk. 

and note your config + any patches applied.

thanks.

> in objc.log for Xcode 4.2.1 on Lion. The undefined
> .objc_class_name_myRootObject symbols
> are still present.

This is expected - it is:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48109
(and needs another pass at the fix).

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

[howarth at nitro dot med.uc.edu]

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

--- Comment #9 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-12-05 15:25:28 UTC ---
Created attachment 25992
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25992
verbose assembly for objc.dg/torture/strings/string1.m  -O2 -flto
-flto-partition=none  -fnext-runtime

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

[howarth at nitro dot med.uc.edu]

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

--- Comment #10 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-12-05 15:30:42 UTC ---
Attached verbose assembly from x86_64-apple-darwin11 using  gcc trunk at
r181974 with http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00241.html generated
using...

/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20111202/gcc/testsuite/objc.dg/torture/strings/string1.m
-O2 -flto -flto-partition=none -fnext-runtime -mno-constant-cfstrings
-Wno-deprecated-declarations
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/i386/libobjc/.libs
-L/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/i386/libobjc/.libs
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20111202/gcc/testsuite/objc.dg/torture/strings/../../../objc-obj-c++-shared/nsconstantstring-class-impl.m
-lobjc -lm -fverbose-asm --save-temps -m32 -o ./string1.exe
[Leaving LTRANS /var/tmp//ccygm7lI.args]
ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in
/var/tmp//ccRjujTE.lto.o

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

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> 2011-12-05 17:23:25 UTC ---
OK - I can reproduce this on Darwin9.

... as things stand I don't think this is the same bug it was originally --
that is solved (the trivial case originally cited does not give rise to two
instances of the ImageInfo var.).

===

The problem is this;  

In the string case there are now two input object files - and of the those
files contains a local L_OBJC_ImageInfo variable. 

Usually ld would get those variables from two input object files and knows to
coalesce them (even tho the section is not marked coalesce) ...

... when LTO is engaged we now produce (I think, correctly, from an LTO
perspective) two local vars in the section - and the linker doesn't get to see
them and do the merge.

----

So, somehow, we need to make these variables merge-able by LTO; such that there
is only one instance in the LTO output to ld.

I think that later versions of the vendor's tools make some of the ObjC
sections merge-able - so that's a possibility -

- otherwise - Honza any suggestions?

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

[iains at gcc dot gnu.org]

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

--- Comment #12 from Iain Sandoe <iains at gcc dot gnu.org> 2011-12-05 21:01:09 UTC ---
(In reply to comment #11)

> I think that later versions of the vendor's tools make some of the ObjC
> sections merge-able - so that's a possibility 

Unfortunately, not the _image_info sections.

===

So .. this is the problem....

We have n object files input to lto.  Each object contains ObjC meta-data...
including a single var in the _image_info section.

Although these image_info  vars will eventually be overlaid, they are not
common-like - because they can be non-zero.

(Darwin's) ld can merge them, because ld knows that the property of the
_image_info section is that it holds a single instance of the L_OBJC_ImageInfo
variable.

So ld can check that these are compatible between objects, and merge/error as
appropriate.

but LTO will concatenate them - leading to two problems:
 (a) the section appears to be too big - complaint from later versions of ld
and 
 (b) they are no longer being error-checked and combined - which might have
much more subtle implications.

> - otherwise - Honza any suggestions?

e.g.
Is there any annotation or hook that we can use to emulate this behavior?

(I don't think DECL_ONE_ONLY is quite right because it might be [legitimately]
possible for the vars to have differing values - I need to check that
carefully)

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 ...

.. maybe move it to be a late (Post Optimization) pass? 

[ISTM, at a first consideration, there should be no need to optimize ObjC
metadata under those circumstances, since it should only be created as required
in response to the remaining (optimized) content]

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

[steven at gcc dot gnu.org]

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

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steven at gcc dot gnu.org

--- Comment #13 from Steven Bosscher <steven at gcc dot gnu.org> 2011-12-06 00:49:26 UTC ---
(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.

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...)

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

[iains at gcc dot 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.

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

[iains at gcc dot gnu.org]

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

--- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> 2012-02-12 14:43:49 UTC ---
this var is a two element array consisting of two integer constants.

the var is marked 'preserve' (because it is read by the OBJC runtime, but not
referenced from the code).

we get one instance of the var per input object file to LTO.

we would like one instance in the output (assuming that the values are really
identical).

so, if we:
 mark the section as SECTION_MERGE
 mark the decl as TREE_READONLY

would we reasonably expect lto to merge them?
if that is not enough, what additional  constraints could be specified?

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

[iains at gcc dot gnu.org]

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

--- Comment #16 from Iain Sandoe <iains at gcc dot gnu.org> ---
*** Bug 55654 has been marked as a duplicate of this bug. ***

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

[iains at gcc dot gnu.org]

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

--- Comment #17 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 30514
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30514&action=edit
proposed fix.

So the problem here is that when we bind multiple objects together (each of
which has an anonymous image_info section) LTO (unlike the system linker)
doens't know that these should be coalesced - and, TBH, I doubt we're going to
teach it about a darwin-specific section ... 

Luckily, the content of the image_info section only depends on command line
flags.

So this is a proposed solution.

1. allow the requisite ObjC flags to be recognized by lto1.

2. don't generate the image_info section in the FE instead ..

3. take note of the flag values, and (IFF there is some ObjC metadata present
in the object) emit the image_info section from the back end.

====

I've checked that this flies on Darwin12 with XCode 4.6.3 [with lto enabled] -
but I don't have the XCode 4.2 configuration on Darwin10.  

(it has also been tested on older versions of the tool-chain).

====

Mike - opinions on the solution?

others: wider testing please

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

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|lto                         |target

--- Comment #18 from Iain Sandoe <iains at gcc dot gnu.org> ---
this is a target issue

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

[iains at gcc dot gnu.org]

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

--- Comment #19 from Iain Sandoe <iains at gcc dot gnu.org> ---
Author: iains
Date: Sat Sep 14 15:36:41 2013
New Revision: 202593

URL: http://gcc.gnu.org/viewcvs?rev=202593&root=gcc&view=rev
Log:

gcc:

       PR target/48094
        * config/darwin.c (darwin_objc2_section): Note if ObjC Metadata is
seen.
        (darwin_objc1_section): Likewise.
        (darwin_file_end): Emit Image Info section when required.

gcc/c-family:

       PR target/48094
        * c.opt (fgnu-runtime, fnext-runtime, fobjc-abi-version,
        fobjc-gc, freplace-objc-classes): Accept for LTO.

gcc/objc:

       PR target/48094
        * objc-next-runtime-abi-01.c (generate_objc_image_info): Remove.
        (objc_generate_v1_next_metadata): Remove generation of ImageInfo.
        * objc-next-runtime-abi-02.c (generate_v2_objc_image_info): Remove.
        (objc_generate_v2_next_metadata): Remove generation of ImageInfo.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c.opt
    trunk/gcc/config/darwin.c
    trunk/gcc/objc/ChangeLog
    trunk/gcc/objc/objc-next-runtime-abi-01.c
    trunk/gcc/objc/objc-next-runtime-abi-02.c

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

[iains at gcc dot gnu.org]

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

--- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> ---
fixed on trunk, but should be back-ported to 4.8/4.7.

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

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |mrs at gcc dot gnu.org
      Known to work|                            |4.9.0
         Resolution|---                         |FIXED
      Known to fail|                            |4.7.0, 4.8.0

--- Comment #21 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> ---
Thanks for the report and the fix guys.  I'd be fine with back port, if someone
wants to develop and test it.

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

[dominiq at gcc dot gnu.org]

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

--- Comment #22 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Mon Apr  7 06:40:18 2014
New Revision: 209175

URL: http://gcc.gnu.org/viewcvs?rev=209175&root=gcc&view=rev
Log:
2014-04-03  Dominique d'Humieres <dominiq@lps.ens.fr>    

    Backport from mainline
    2013-09-14  Iain Sandoe <iains@gcc.gnu.org>

gcc:

    PR target/48094
    * config/darwin.c (darwin_objc2_section): Note if ObjC Metadata is seen.
    (darwin_objc1_section): Likewise.
    (darwin_file_end): Emit Image Info section when required.

gcc/c-family:

    PR target/48094
    * c.opt (fgnu-runtime, fnext-runtime, fobjc-abi-version,
    fobjc-gc, freplace-objc-classes): Accept for LTO.

gcc/objc:

    PR target/48094
    * objc-next-runtime-abi-01.c (generate_objc_image_info): Remove.
    (objc_generate_v1_next_metadata): Remove generation of ImageInfo.
    * objc-next-runtime-abi-02.c (generate_v2_objc_image_info): Remove.
    (objc_generate_v2_next_metadata): Remove generation of ImageInfo.


Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/c-family/ChangeLog
    branches/gcc-4_8-branch/gcc/c-family/c.opt
    branches/gcc-4_8-branch/gcc/config/darwin.c
    branches/gcc-4_8-branch/gcc/objc/ChangeLog
    branches/gcc-4_8-branch/gcc/objc/objc-next-runtime-abi-01.c
    branches/gcc-4_8-branch/gcc/objc/objc-next-runtime-abi-02.c

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

[dominiq at gcc dot gnu.org]

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

--- Comment #23 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Mon Apr  7 08:00:55 2014
New Revision: 209176

URL: http://gcc.gnu.org/viewcvs?rev=209176&root=gcc&view=rev
Log:
2014-04-07  Dominique d'Humieres <dominiq@lps.ens.fr>    

        Backport from mainline
        2013-09-14  Iain Sandoe <iains@gcc.gnu.org>

gcc:

    PR target/48094
    * config/darwin.c (darwin_objc2_section): Note if ObjC Metadata is seen.
    (darwin_objc1_section): Likewise.
    (darwin_file_end): Emit Image Info section when required.

gcc/c-family:

    PR target/48094
    * c.opt (fgnu-runtime, fnext-runtime, fobjc-abi-version,
    fobjc-gc, freplace-objc-classes): Accept for LTO.

gcc/objc:

    PR target/48094
    * objc-next-runtime-abi-01.c (generate_objc_image_info): Remove.
    (objc_generate_v1_next_metadata): Remove generation of ImageInfo.
    * objc-next-runtime-abi-02.c (generate_v2_objc_image_info): Remove.
    (objc_generate_v2_next_metadata): Remove generation of ImageInfo.


Modified:
    branches/gcc-4_7-branch/gcc/ChangeLog
    branches/gcc-4_7-branch/gcc/c-family/ChangeLog
    branches/gcc-4_7-branch/gcc/c-family/c.opt
    branches/gcc-4_7-branch/gcc/config/darwin.c
    branches/gcc-4_7-branch/gcc/objc/ChangeLog
    branches/gcc-4_7-branch/gcc/objc/objc-next-runtime-abi-01.c
    branches/gcc-4_7-branch/gcc/objc/objc-next-runtime-abi-02.c