https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104671
--- Comment #4 from Nicholas Piggin <npiggin at gmail dot com> ---
(In reply to Alan Modra from comment #3)
> (In reply to Nicholas Piggin from comment #0)
> > Commit e154242724b084380e3221df7c08fcdbd8460674 ("Don't pass -many to the
> > assembler") also added a workaround emitting a ".machine" directive to the
> > top of each generated .s file
>
> Nope, wrong commit. The added .machine there is one in response to an
> attribute or pragma selecting a different cpu. ie. it's in response to user
> source code saying "compile this function for this particular cpu, not
> necessarily the one given on the gcc command line".
>
> Commit b9f12a01bedb5 is the first commit that added .machine to the top of
> assembly files. The early .machine was not always emitted by that
> particular commit. Always emitting the early .machine came later.
Thanks for the correction.
And thank you for taking the time to write the detailed explanation in bug
#102485, it's very helpful. Not sure where it leaves this report wrt gcc, but
upstream binutils solves the problem for me so I would be happy to consider it
resolved.
It is what it is, we can patch Linux to fix the build issues, the proposed
fixes don't look too onerous. And we need to remove -many from our build anyway
(should have done so a long time ago) so this will give the necessary prod.
