From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19289 invoked by alias); 6 Dec 2011 09:13:19 -0000 Received: (qmail 19280 invoked by uid 22791); 6 Dec 2011 09:13:18 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Dec 2011 09:13:05 +0000 From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto Date: Tue, 06 Dec 2011 09:13:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-12/txt/msg00531.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094 --- Comment #14 from Iain Sandoe 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.