From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 776 invoked by alias); 30 May 2011 15:30:57 -0000 Received: (qmail 754 invoked by uid 22791); 30 May 2011 15:30:55 -0000 X-SWARE-Spam-Status: No, hits=-2.7 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; Mon, 30 May 2011 15:30:39 +0000 From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/48108] lto should be containerized in a single mach-o section on darwin X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: lto X-Bugzilla-Severity: enhancement 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: Status Last reconfirmed Ever Confirmed 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 Date: Mon, 30 May 2011 16:02:00 -0000 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-05/txt/msg03028.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 Iain Sandoe changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2011.05.30 15:30:05 Ever Confirmed|0 |1 --- Comment #12 from Iain Sandoe 2011-05-30 15:30:05 UTC --- (In reply to comment #11) > Created attachment 24397 [details] > Iain's work in progress for LTO containerization Sorry that I can't commit any time to GCC right now. The main outstanding issue with this patch is that the intermediate files created by GCC are still unbounded in the number of sections. So long as the only consumer of those files is GCC, no problem (since the arrangement has been made to ensure that relocatable sections come first). However, those intermediate files are still technically 'wrong' and therefore the writer should be updated to do the same encapsulation. Once that is done there will be no need to retain the ability to recognize GCC vs 'normal' objects.