From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26853 invoked by alias); 28 Apr 2015 19:22:44 -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 26418 invoked by uid 48); 28 Apr 2015 19:22:39 -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 19:22: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: 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/msg02448.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #17 from prathamesh3492 at gcc dot gnu.org --- (In reply to clyon from comment #16) > (In reply to prathamesh3492 from comment #15) > > > I am not understanding why vfpv3-d16 appears in collect_gcc_options in > > run_gcc(). > Isn't this because you configured GCC --with-fpu=vfpv3-d16? COLLECT_GCC_OPTIONS is set by gcc.c:set_collect_gcc_options(): /* Build COLLECT_GCC_OPTIONS to have all of the options specified to the compiler. */ obstack_grow (&collect_obstack, "COLLECT_GCC_OPTIONS=", sizeof ("COLLECT_GCC_OPTIONS=") - 1); and at the end of set_collect_gcc_options(): xputenv (XOBFINISH (&collect_obstack, char *)); which makes it environment variable. set_collect_gcc_options() is called by do_spec, which is called by driver::maybe_run_linker(), before executing linker. So the driver has no knowledge of options passed at compile-time, it sets the default -mfpu=vfpv3-d16. When lto-wrapper executes, it gets linker command line options from environment variable COLLECT_GCC_OPTIONS, which contains -mfpu=vfpv3-d16. and since that was being appended after compile-time options (fdecoded_options), -mfpu=vfpv3-d16 overrides -mfpu=neon. This also explains why it works in one shot arm-linux-gnueabihf -flto -mfpu=neon test.c COLLECT_GCC_OPTIONS will have "-mfpu=neon" since it's mentioned on command line, and lto-wrapper has access to this COLLECT_GCC_OPTIONS. When compiler and linker are run separately, at link time, the driver has no knowledege of flags of compile-time run, and hence sets default flags in COLLECT_GCC_OPTIONS. I think correct way to fix would be in run_gcc() to get values from COLLECT_GCC_OPTIONS in decoded_options as is currently done. run_gcc() walks through options in object file and saves it in fdecoded_options. So override the value in decoded_options for the same option found in fdecoded_options. Would that be a right approach ? Thank you, Prathamesh