On Tue, Oct 29, 2019 at 8:26 AM Bernhard Reutner-Fischer <rep.dot....@gmail.com> wrote: > > On 28 October 2019 23:08:10 CET, Richard Earnshaw > <richard.earns...@foss.arm.com> wrote: > >On 28/10/2019 21:52, Bernhard Reutner-Fischer wrote: > >> On Mon, 28 Oct 2019 11:53:06 +1100 > >> Kugan Vivekanandarajah <kugan.vivekanandara...@linaro.org> wrote: > >> > >>> On Wed, 23 Oct 2019 at 23:07, Richard Biener > ><richard.guent...@gmail.com> wrote: > >> > >>>> Did you try this with multiple assembler options? I see you stream > >>>> them as -Wa,-mfpu=xyz,-mthumb but then compare the whole > >>>> option strings so a mismatch with -Wa,-mthumb,-mfpu=xyz would be > >> > >> indeed, i'd have expected some kind of sorting, but i don't see it in > >> the proposed patch? > > > >Why? If the options interact with each other, then sorting could > >change > >the meaning. We could only sort the options if we knew that couldn't > > > Right of course, retaining the given order is a must. Not sure what I was > thinking.
But does it work in the end? I can't find right now but I do remember that some specs processing adds assembler options from compiler options like -march=xyz. If LTRANS processing does this again then this will disrupt order from the COLLECT_AS options extracted at build time. Richard. > thanks,
