Hi! On Wed, Dec 14, 2022 at 03:29:02PM -0500, Michael Meissner wrote: > These 3 patches fix the problems with building GCC on PowerPC systems when > long > double is configured to use the IEEE 128-bit format.
If you are strictly trying to fix a bootstrap problem, you should say so: it should be very prominent in the proposed commit message, and that message should be not much more than that. And the patch should do nothing else. *Every* patch should do just one thing, but for fixes it is even more important (how will we ever get into any stable state if we always do random stuff?) > The basic issue is internally within GCC there are several types for 128-bit > floating point. The types are: There also are three *modes*, but there should be only IFmode and KFmode, and TFmode should be just a #define that resolves to either, not a separate mode. This simplifies things a lot. It should have always been that way, as we talked about way back when already. But you didn't want to implement things that way. This is on my plate now (for GCC 14). > 3) The type for _Float128. This type is always IEEE 128-bit if it > exists. And if there is no IEEE QP type? What should _Float128 be then? Largely academic, because there always *should* be a QP type (and mode). This is a long-standing shortcoming as well. I will finally fix that myself for GCC 14 as well, simplifying many things. > Like __ibm128, it uses the long double type if > long double is IEEE 128-bit, Which is completely upside down, of course. The basic types should be basic and always exist. Things like long double can use some indirection and/or copy stuff over. Anything else is just a maze of twisty little passages. A fun game if you like that sort of thing, maybe, but instead of solving problems it causes more :-( > After these patches, there are 3 specific tests and 1 set of tests that fail > when using IEEE 128-bit long double: > > 1) fp128_conversions.c: I haven't looked at yet; That needs to be looked at before these patches can be approved. > 2) pr105334.c: This is a bug that __ibm128 doesn't work if the default > long double is IEEE 128-bit and you use the options: -mlong-double-128 > -msoft-float (i.e. no -mabi=ibmlongdouble). I believe I have patches > for this floating around. Ditto. > 3) The g++.dg/cpp23/ext-floating1.C test is failing. I believe we need > to > dig in to fix PowerPC specific ISO C/C++ 2x _Float128 support. I have > looked at it yet. Ditto. > 4) All/some of the G++ modules tests fail. This is PR 98645, and it is > assigned to Nathan Sidwell. And this one too. Any new failures need analysis. Always. This is why we have regression tests at all! Segher
