This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RS6000] Don't pass -many to the assembler


On Mon, Nov 12, 2018 at 04:17:51PM +0000, Michael Matz wrote:
> Hi,
> 
> On Mon, 12 Nov 2018, Segher Boessenkool wrote:
> 
> > > > Wouldn't this also break compiling code that contains power9 
> > > > instructions but guarded by runtime tests to only be executed on 
> > > > power9 machines?  That seems a valid usecase, and it'd be bad if the 
> > > > assembler fails to compile such.  (You can't use -mcpu=power9 as 
> > > > work around as the other unguarded code is not supposed to be using 
> > > > power9 insns).
> > > 
> > > You'll need to put .machine directives around them.
> > 
> > My worry with that is there may be too much legacy code that does not do 
> > this :-(
> 
> We'll see once we put gcc9 through a distro build.  My worry really only 
> was that the change would result in compile breakage without a sensible 
> solution.  (I'll just give all packages whose build failures prevent gcc9 
> from being the new system compiler to Alan for fixing ;-) ).

Heh.  I've been using the patch (or one like it) myself for over 2
years, but of course I don't tend to compile whole distros.  The
length of time I've had it baking in my tree says something about my
hesitation to post the patch more than anything else.  Note that you
can easily "fix" package build failures by adding -Wa,-many to
CFLAGS.

For people developing new code, it's the right way to go, and
especially so for people working on gcc itself.  For people just
wanting stuff to compile, not so much.  I fully expect a chorus of
*MORON* or worse to come from the likes of the linux kernel rabble.

-- 
Alan Modra
Australia Development Lab, IBM


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]