This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR47785] COLLECT_AS_OPTIONS
On Tue, Oct 29, 2019 at 8:26 AM Bernhard Reutner-Fischer
<rep.dot.nop@gmail.com> wrote:
>
> On 28 October 2019 23:08:10 CET, Richard Earnshaw <Richard.Earnshaw@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.vivekanandarajah@linaro.org> wrote:
> >>
> >>> On Wed, 23 Oct 2019 at 23:07, Richard Biener
> ><richard.guenther@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,