From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25305 invoked by alias); 26 Feb 2011 02:14:59 -0000 Received: (qmail 25221 invoked by uid 22791); 26 Feb 2011 02:14:57 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-iw0-f169.google.com (HELO mail-iw0-f169.google.com) (209.85.214.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 26 Feb 2011 02:14:52 +0000 Received: by iwl42 with SMTP id 42so2023548iwl.0 for ; Fri, 25 Feb 2011 18:14:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.45.201 with SMTP id ul9mr602743icb.156.1298686490142; Fri, 25 Feb 2011 18:14:50 -0800 (PST) Received: by 10.42.60.129 with HTTP; Fri, 25 Feb 2011 18:14:50 -0800 (PST) In-Reply-To: <4D684CB8.6020106@gmail.com> References: <4D684CB8.6020106@gmail.com> Date: Sat, 26 Feb 2011 02:14:00 -0000 Message-ID: Subject: Re: [PATCH,trunk+2.20] Fix issues in ld.bfd plugin interface [0/6] From: "H.J. Lu" To: Dave Korn Cc: "binutils@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00340.txt.bz2 On Fri, Feb 25, 2011 at 4:43 PM, Dave Korn wro= te: > > =A0After my patches, LD gives the following results: > >> FAIL: ld-plugin/lto-4r-a >> FAIL: ld-plugin/lto-4r-b >> FAIL: ld-plugin/lto-4r-c >> FAIL: ld-plugin/lto-4r-d >> FAIL: LTO 4a >> FAIL: LTO 4c >> FAIL: LTO 4d >> FAIL: LTO 10 >> FAIL: LTO 12a >> FAIL: LTO 12b >> FAIL: LTO 15 > > =A0Relative to current LD, that has fixes to 12365, 5 symbol, 3b and 5. = =A0The > new FAILures on 12a/b and 15 are actually a difference of interpretation = about > how the linker is supposed to work between me and HJ's code. =A0The tests= assume > that it is not possible to override builtins such as __udivdi3 or memcpy,= but > it works OK with the attached patches, so I'm not sure why these tests do= what > they do. =A0For example, test LTO 15 has this source file compiled as an = object: > >> #include >> >> int main(int argc, char **argv) >> { >> =A0 printf ("PASS\n"); >> =A0 return (int) ((unsigned long long) argc / argv[0][0]); >> } > > ... and this one in a library archive member: > >> extern void abort (void); >> unsigned long long >> __udivdi3(unsigned long long n, unsigned long long d) >> { >> =A0 abort (); >> =A0 return n + d; >> } > > ... so I would have thought that the ideal case would be for an LTO link = to > mimic a non-LTO link, and pull in the definition of __udivdi3 there and a= bort. > > =A0That aside, the only thing that LD still doesn't handle after these pa= tches > is mixed object files that are created by using "ld -r" to merge multiple= IR > and non-IR object files. > The question is if LTO linker should link in non-LTO copy of the same funct= ion and ignore the LTO-IR copy: [hjl@gnu-6 pr12496-2]$ make as --32 -o start.o start.s /usr/gcc-4.6/bin/gcc -m32 -B./ -flto -c -o main.o main.c /usr/gcc-4.6/bin/gcc -m32 -B./ -flto -c -o div.o div.c ar rv libdiv.a div.o ar: creating libdiv.a a - div.o /usr/gcc-4.6/bin/gcc -m32 -B./ -O2 -flto -nostdlib -o prog -Wl,--start-group start.o main.o libdiv.a -Wl,--end-group Here div.o is compiled with -O0 -flto and the final link is compiled with -O2 -flto. I would expect div.c is compiled with -O2 -flto, not -O0, if div.c is linked in. Am I expecting too much? --=20 H.J.