https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 28 Apr 2015, prathamesh3492 at gcc dot gnu.org wrote: > 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 ? No, link-time options always override compile-time ones. I suspect the fix will be to somehow avoid setting defaults when linking?
