https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #25 from ramana.radhakrishnan at arm dot com <ramana.radhakrishnan at arm dot com> --- On 29/04/15 09:09, rguenther at suse dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 > > --- Comment #24 from rguenther at suse dot de <rguenther at suse dot de> --- > On Wed, 29 Apr 2015, ramana at gcc dot gnu.org wrote: > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 >> >> --- Comment #23 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> --- >> (In reply to rguent...@suse.de from comment #20) >>> 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? >> >> Well I'm not sure how easy that's going to be - You will need some amount of >> defaults to get through especially if the user hasn't provided the options in >> the first place :( . > > The other option is to special-case only those options that are slipping > in that way (-march, -mtune, -mcpu, -mfpu?) and emit those always first, > hoping that explicit ones will override that. Of course lto-wrapper > cannot distinguish between implicitely and explicitely such given > arguments at link-time. Which means the only solution would be to > completely ignore these at link-time. IMHO that will cause more problems. Alternatively, add options_default_specs in the beginning and then filter out all those values of options that are the same as the default options hoping that the user doesn't put that back in again. But again it's sticky tape and doesnt' really fix the problem. I'm not sure we're improving the situation in anyway by putting in the hack - it just pushes a compile time breakage into possibly subtle runtime failure which can easily be achieved by adding the "relaxed option" in this case -mfpu=neon to the command line at link time. At least then it's evident to the user that they need to do something specific to their use-case to get LTO working or fail very quickly if their code relies on absence of SIMD code in the default case or in the case without auto-detection. I'm pretty sure this will be the first thing to sort out when trying to build kernels with LTO for e.g.. ..... So, I guess I'm voting for doing this properly with target attributes rather than putting one more bit of sticky tape in a pretty painful area of the compiler. > > But I suspect this might break otherwise working cases (due to the fact > that which -march/-mtune/-mcpu/-mfpu options lto-wrapper chooses from > the object files is essentially "random" if they don't agree for all > objects). > > It's really unfortunate that these configure-time defaults appear > as regular user command-line arguments :( I suppose this was done > to make them visible to specs processing. > Yeah, sigh. regards Ramana
