From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35077 invoked by alias); 28 Apr 2015 22:40:11 -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 35002 invoked by uid 48); 28 Apr 2015 22:40:07 -0000 From: "prathamesh3492 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: Tue, 28 Apr 2015 22:40: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: prathamesh3492 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: attachments.created 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/msg02465.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #18 from prathamesh3492 at gcc dot gnu.org --- Created attachment 35420 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35420&action=edit 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