[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985

--- Comment #32 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #31)
> > --- Comment #29 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> [...]
> > Ok, what's the minimum configuration I need to build here?
> >
> > srcdir/configure --build=sparc-sun-solaris2.11
> >
> > srcdir/configure --build=sparc-sun-solaris2.11 --without-gnu-as
> > --without-gnu-ld
> >
> > ??
> 
>   srcdir/configure --build=sparcv9-sun-solaris2.11 --without-gnu-as
>   --with-as=/usr/bin/as --without-gnu-ld --with-ld=/usr/bin/ld

OK, I'll add this to my notes.  Thanks.

BTW, the above seems like it would be a perfect thing to put in /etc/motd :).

> 
> should do the trick.
> 
> Preferably prepend /usr/gnu/bin to PATH.
> 
> > I really don't care how it builds, I just want the bare minimum so I can
> > bootstrap and run tests.
> >
> > A minor rant, but why can't all this be set up automatically in the compile
> > farm machines?  Keeping track of minor nuances of each architecture is
> > distracting.  They should all be set up, whether by setting default paths in
> 
> Agreed, but you always run into stuff like this when leaving Linux (like
> AIX, HP-UX, or macOS).  PATHs won't help much for reasons explained in
> install.texi.
> 
> > /etc/profile or whatever, or by having the relevant patches in GCC's source
> > base, such that they work with src/configure && make.
> 
> But what should be the default: GNU or native tools?  You have choices
> here and need to decide what you need/want.  No one can do this for you.

My guess would be to use gnu tools if available, cause those would be
"guaranteed" to work correctly to build gcc?

> 
> > I know this isn't your fault, but if more cfarm boxes where set up to go with
> > no surprises, I'd add more boxen to my testing harness.
> 
> Well, I *did* set up the Solaris cfarm systems, actually ;-)  I see your
> point, but things are not that simple unfortunately.  And GCC's
> configure doesn't need to cater to users of the cfarm only...
> 
> Some of the issues (like the need for --build) have been caused by
> upstream (like the config.guess maintainers that refuse to listen to
> reason ;-).  I thought about improving the --with-as/ld situation; maybe
> something can be done there.

Thanks for the explanation.