From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111986 invoked by alias); 29 Apr 2015 07:42:54 -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 Received: (qmail 111909 invoked by uid 48); 29 Apr 2015 07:42:50 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available Date: Wed, 29 Apr 2015 07:42:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: prathamesh3492 at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-04/txt/msg02484.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #21 from Richard Biener --- (In reply to prathamesh3492 from comment #18) > Created attachment 35420 [details] > patch to override default options by options in object file > > Hi, > > The following untested patch gives preference to option value in object file. > In run_gcc(), > options from COLLECT_GCC_OPTIONS which are taken from command line are > stored in decoded_options. > options from object file are stored in fdecoded_options. > so override the option in decoded_options if it is present in > fdecoded_options. > > With the patch this works: > arm-linux-gnueabihf-gcc test.c -mfpu=neon -flto -c > arm-linux-gnueabihf-gcc test.o -flto > only passes -mfpu=neon to lto1 > > However the patch doesn't work when same option is passed different values > at compile and link-time: > arm-linux-gnuebihf-gcc test.c -mfpu=neon -flto -c > arm-linux-gnueabihf-gcc test.o -mfpu=vfpv3-d16 -flto > > In this case, -mfpu=neon is still passed to lto1, since the patch prefers > option value from object file. > Without the patch, the option from the command line was given preference. > > for both the following cases: > arm-linux-gnueabihf-gcc test.o -flto > arm-linux-gnueabihf-gcc test.o -flto -mfpu=vfpv3-d16 > > COLLECT_GCC_OPTIONS contains "-mfpu=vfpv3-d16", however in the first case it > isn't explictly passed by user, so passing -mfpu=neon > would be correct. In the second case, since -mfpu=vfpv3-d16 is passed > intentionally by user, should it be considered > as an error - "conflicting options" ? > > Unfortunately, it looks like there is no way to distinguish between options > defined by default and explicitly passed options from COLLECT_GCC_OPTIONS > and that's the only way command line options are passed to lto-wrapper from > the driver. One way would be to modify COLLECT_GCC_OPTIONS in the driver to > indicate which options were explicitly passed from command line. > For instance, additionally COLLECT_GCC_OPTIONS would contain > "-mfpu=vfpv3-d16-explicit" to indiciate that -mfpu=vfpv3-d16 was > passed from command line and not set by default. In lto-wrapper the options > could be parsed to check if they have "explicit" suffix and thus distinguish > between explicit and defualt defined options. > Does that sound reasonable ? I would be grateful for suggestions. > > Thank you, > Prathamesh As said the patch is wrong.