[V2] Use system default for long double if not specified on PowerPC.

  Use system default for long double unless it is overridden.

If the user did not specify a default long double format when configuring
GCC, use the long double default from the host compiler.

I tested this on the following systems.  There were no regressions:

    *	Big endian Linux power8 using --with-cpu=power8
    *	Little endian Linux power9 using --with-cpu=power9
    *	Little endian Linux power10 using --with-cpu=power10
    *	Little endian Fedora rawhide power10 using --with-cpu=power10 that the
	default was changed to use IEEE 128-bit. I did not specify
	--with-long-double-format=ieee and it correctly defaulted to IEEE.
    *	I also built a compiler on the above Fedora rawhide system, explicitly
	setting the type to IBM, and it did use the IBM format.

Can I check this into the master branch?  I also think this should be back
ported to GCC 11.  Can I do this also?


2022-02-04  Michael Meissner  <meissner@the-meissners.org>

gcc/
	* config/rs6000/rs6000.cc (TARGET_IEEEQUAD_DEFAULT): If the
	host compiler defaults to IEEE 128-bit long double, make that the
	default for this build unless it was overridden via the
	--with-long-double-format= configuration option.
---
 gcc/config/rs6000/rs6000.cc | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)
  

On Feb 04 2022, Michael Meissner via Gcc-patches wrote:

> If the user did not specify a default long double format when configuring
> GCC, use the long double default from the host compiler.

That doesn't make any sense.  The host compiler can be any random
compiler completely unrelated to the target.
  

On Fri, Feb 04, 2022 at 04:43:53PM +0100, Andreas Schwab wrote:
> On Feb 04 2022, Michael Meissner via Gcc-patches wrote:
> > If the user did not specify a default long double format when configuring
> > GCC, use the long double default from the host compiler.
> 
> That doesn't make any sense.  The host compiler can be any random
> compiler completely unrelated to the target.

Yes, see <https://gcc.gnu.org/onlinedocs/gccint/Portability.html>.

It also goes against the basic GCC policy that results should be
reproducible.  We *do* have some existing cases where the compiler
changes behaviour based on whether e.g. binutils is too old to have a
certain feature.  Either a) such cases are ancient, everyone has a newer
version in practice, we could just require this; or b) those cases cause
no end of problems, everyone is much better off if we tell the user at
configuration time to get newer stuff, or if it causes a clear error in
the first place we can just let it do that.

Also.  We cannot have confidence that our compiler does anything correct
or good if we cannot test it.  If we let the testing matrix explode
exponentially we cannot test even the reasonable cases.  It will make
the support job a lot harder as well: users will not report what they
used when configuring and building the compiler when they report a
problem, even more so because in all likelyhood it was someone else who
did that building!  And our own diagnostic for this (the gcc -v output)
dows not say what defaults the build compiler used.

I already NAKed this patch for weeks, and I do it again now.


Segher
  

On 2/4/22 12:03 PM, Segher Boessenkool wrote:
> On Fri, Feb 04, 2022 at 04:43:53PM +0100, Andreas Schwab wrote:
>> On Feb 04 2022, Michael Meissner via Gcc-patches wrote:
>>> If the user did not specify a default long double format when configuring
>>> GCC, use the long double default from the host compiler.
>>
>> That doesn't make any sense.  The host compiler can be any random
>> compiler completely unrelated to the target.
> 
> Yes, see <https://gcc.gnu.org/onlinedocs/gccint/Portability.html>.
[snip]
> I already NAKed this patch for weeks, and I do it again now.

Did you NAK the patch due to its specific implementation or are you
even against the aim of the patch, namely that gcc configure tries
to determine the long double default of the underlying system and
matches that?

Peter
  

On Fri, Feb 04, 2022 at 02:10:03PM -0600, Peter Bergner wrote:
> On 2/4/22 12:03 PM, Segher Boessenkool wrote:
> > On Fri, Feb 04, 2022 at 04:43:53PM +0100, Andreas Schwab wrote:
> >> On Feb 04 2022, Michael Meissner via Gcc-patches wrote:
> >>> If the user did not specify a default long double format when configuring
> >>> GCC, use the long double default from the host compiler.
> >>
> >> That doesn't make any sense.  The host compiler can be any random
> >> compiler completely unrelated to the target.
> > 
> > Yes, see <https://gcc.gnu.org/onlinedocs/gccint/Portability.html>.
> [snip]
> > I already NAKed this patch for weeks, and I do it again now.
> 
> Did you NAK the patch due to its specific implementation or are you
> even against the aim of the patch, namely that gcc configure tries
> to determine the long double default of the underlying system and
> matches that?

As I said before, I didn't even read the patch, just the one line
summary was enough for a NAK.  If the patch in fact does something else,
then it is still incorrect, and needs a very different subject and
summary.

I hope you see how "using the default of the underlying system" is
questionable in itself, but is something completely different from using
the default of the build compiler, which makes even less sense.

You want a configure flag to set the default long double format to be
IEEE QP.  This cannot be enabled by default until a (big) majority of
systems "in the wild" will work with that (only on powerpc64le-linux
or some *big* thing like that is fine, only default it to enabled there
then).  At that point in time, configure shouls complain, and the user
would have to explicitly *disable* it to build without that support.

Anything else is pretend progress and costs us too much.  Yes, this is
a "flag day", but only for the default.  We will still support the
double-double format for a loooooong time, if only because there are no
concrete plans for moving most of its users (or no plans at all is more
truthful actually)!


Segher
  

On 2/4/22 4:26 PM, Segher Boessenkool wrote:
> As I said before, I didn't even read the patch, just the one line
> summary was enough for a NAK.  If the patch in fact does something else,
> then it is still incorrect, and needs a very different subject and
> summary.
> 
> I hope you see how "using the default of the underlying system" is
> questionable in itself, but is something completely different from using
> the default of the build compiler, which makes even less sense.
> 
> You want a configure flag to set the default long double format to be
> IEEE QP.  This cannot be enabled by default until a (big) majority of
> systems "in the wild" will work with that (only on powerpc64le-linux
> or some *big* thing like that is fine, only default it to enabled there
> then).  At that point in time, configure shouls complain, and the user
> would have to explicitly *disable* it to build without that support.

Can you please clarify one thing for me.  Do you think it's possible
that we can come up with some type of configure patch that automatically
sets the long double default given something on the system we can test
for or do you think that's impossible and we'll just have to live with
explicitly using a configure option to set the default?

...at least until some time in the far future when enough systems/distros
have changed to IEEE128 that we can change the default without a test.

Peter
  

On Feb 08 2022, Peter Bergner wrote:

> Can you please clarify one thing for me.  Do you think it's possible
> that we can come up with some type of configure patch that automatically
> sets the long double default given something on the system we can test
> for or do you think that's impossible and we'll just have to live with
> explicitly using a configure option to set the default?

It should be handled the same as the double->long double switch.
  

Hi Andreas,

On Tue, Feb 08, 2022 at 06:36:57PM +0100, Andreas Schwab wrote:
> On Feb 08 2022, Peter Bergner wrote:
> > Can you please clarify one thing for me.  Do you think it's possible
> > that we can come up with some type of configure patch that automatically
> > sets the long double default given something on the system we can test
> > for or do you think that's impossible and we'll just have to live with
> > explicitly using a configure option to set the default?
> 
> It should be handled the same as the double->long double switch.

So how was that done?  It's not something I can find online ("long
double conversion" does not find it, heh).  Was it just a flag day where
the default was changed?

IMO it is a bad idea to change configuration without the user asking for
it (and even doing that silently).  It is hard enough and painful enough
to do this conversion in the first place, we do not need twice as many
user configurations (that are not even shown by gcc -v, etc.)

Testing is hard.  Testing twice as many configurations is twice as hard.
The only outcome that can be reasonably expected is that at least half
of the new configurations will not be tested at all.  And that is very
expensive, because there will be a lot of wasted work and frustration
for whoever gets to handle bug reports, and ditto for whoever gets to
deal with a bug that was not handled (aka, a worse user experience).

The apparent goal here is to give users compilers that default to IEEE
QP long double earlier.  That is a fine goal, but it should be achieved
bu actually changing the default earlier, not by leaving behind a large
fraction of users!


Segher
  

On Feb 09 2022, Segher Boessenkool wrote:

> Hi Andreas,
>
> On Tue, Feb 08, 2022 at 06:36:57PM +0100, Andreas Schwab wrote:
>> On Feb 08 2022, Peter Bergner wrote:
>> > Can you please clarify one thing for me.  Do you think it's possible
>> > that we can come up with some type of configure patch that automatically
>> > sets the long double default given something on the system we can test
>> > for or do you think that's impossible and we'll just have to live with
>> > explicitly using a configure option to set the default?
>> 
>> It should be handled the same as the double->long double switch.
>
> So how was that done?

I thnk commit ed965309dad added that.