Message ID | Yf1Ggueq2MMZUnRS@toto.the-meissners.org |
---|---|
State | New |
Headers | show |
Series | [V2] Use system default for long double if not specified on PowerPC. | expand |
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.
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc index 666dec694a8..0595855568c 100644 --- a/gcc/config/rs6000/rs6000.cc +++ b/gcc/config/rs6000/rs6000.cc @@ -91,10 +91,17 @@ explicitly redefine TARGET_IEEEQUAD and TARGET_IEEEQUAD_DEFAULT to 0, so those systems will not pick up this default. This needs to be after all of the include files, so that POWERPC_LINUX and POWERPC_FREEBSD are - properly defined. */ + properly defined. In addition, the --with-long-double-format + configuration option also sets TARGET_IEEEQUAD_DEFAULT. + + If the host compiler uses IEEE 128-bit long doubles, make the default to + also use IEEE 128-bit long doubles unless the --with-long-double-format + configuration switch was used. */ #ifndef TARGET_IEEEQUAD_DEFAULT #if !defined (POWERPC_LINUX) && !defined (POWERPC_FREEBSD) #define TARGET_IEEEQUAD_DEFAULT 1 +#elif defined (__LONG_DOUBLE_IEEE128__) +#define TARGET_IEEEQUAD_DEFAULT 1 #else #define TARGET_IEEEQUAD_DEFAULT 0 #endif