From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6530 invoked by alias); 4 Sep 2012 23:06:44 -0000 Received: (qmail 6469 invoked by uid 22791); 4 Sep 2012 23:06:43 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED,TW_BJ 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, 04 Sep 2012 23:06:30 +0000 From: "ramana at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together Date: Tue, 04 Sep 2012 23:06:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ramana at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED 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: 2012-09/txt/msg00304.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 --- Comment #6 from Ramana Radhakrishnan 2012-09-04 23:06:29 UTC --- Oh I see, my bad to have missed your command line. Sorry. I see what's going on here. It's just luck that this works on x86_64 with your invocation. >$ objdump -h non-collected-strings.o | grep str >non-collected-strings.o: file format elf64-x86-64 > 3 .rodata.str1.8 0000001f 0000000000000000 0000000000000000 00000040 2**3 > 5 .rodata.str1.1 0000001b 0000000000000000 0000000000000000 0000006f 2**0 Try with -Os on x86_64 and it should fail there as well on trunk / earlier versions of GCC. Notice one string has an alignment of 8 and the other 1 and that's what drew my attention to the funniness in this testcase. The reason for this is the play with CONSTANT_ALIGNMENT in the backends. If the strings gets the same alignment you end up with the strings in the same sections which means the whole thing doesn't work and if they have a different alignment as with your invocation, it all works fine. :( regards, ramana