On Fri, Dec 11, 2020 at 05:07:28PM -0500, Michael Meissner wrote:
> On Thu, Dec 10, 2020 at 03:20:01PM -0600, Segher Boessenkool wrote:
> > > We use the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change this
> > > name. We
> > > - only do this if the default is that long double is IBM extended
> > > double, and
> > > - the user asked for IEEE 128-bit. */
> > > + only do this transformation if the __float128 type is enabled. This
> > > + prevents us from doing the transformation on older 32-bit ports that
> > > might
> > > + have enabled using IEEE 128-bit floating point as the default long
> > > double
> > > + type. */
> >
> > I still don't understand why you want to support some hypothetical and
> > untested configuration.
>
> I'm not sure what you mean by hypothetical and untested configuration.
Do you know any 32-bit config that uses IEEE QP float?
You should be able to use it (and on *all* systems even, that just
requires soft float for it, and it would make testing HUGELY easier, but
you prefer having ten times are much frustrating work later over having
a little bit of work now. But that aside.), but it isn't the default on
any 32-bit config. So it is hypothetical, and because of that, it
obviously cannot be tested.
> If you
> build a default configuration on a big endian system (i.e. do not use
> --with-cpu specifying at least power7), the __float128 type is not enabled by
> default, because you need access to the VSX vector registers.
It *cannot* be enabled on most older systems. This is a big problem.
If we *did* have soft float QP float, we could even enable it as the
default long double type on many systems. This is *much* less
problematic than switching the long double default on some complex
subset of configurations.
> > > + /* { dg-final { scan-assembler {\mbl __ynieee128} } } */
> >
> > This kind of thing does not portably work (the function names can have
> > various prefixes added).
>
> Why would it have prefixes? Can you suggest a better way of doing the test?
Many testcases do it already. Like, builtins-1.c has
{\mbl \.?_?__divdi3\M}. It depends on what ABI you have.
> There are lots of different long names that need to get mapped if long doubles
> are IEEE 128-bit. This test just tries to test every function to make sure it
> got mapped appropriately.
It isn't portable enough. I know you think that only powerpc64le-linux
has, and can ever have, and will ever have, QP float. But that is
wrong. And I don't want more work than necessary because you just
randomly restrict things.
You know this, I have said it tens of times already.
> We can't do a link test without requiring that GLIBC is 2.32 or newer, since
> the older GLIBCs don't have all of the symbols.
You should not require glibc for this at all. All compiler support
routines belong in libgcc. That is what libgcc *is*.
Not wanting to do that work gives crazy restrictions already, and will
be even more work in the future.
> And the link test would only
> work on little endian ELFV2 systems, since big endian GLIBC 2.32 does not
> export any of the float128 stuff.
Yes, more technical debt. (I hate that term, but it is appropriate
here).
> > I cannot understand this code, and it does seem far from obviously
> > correct. But, okay for trunk if you handle all fallout (and I mean all,
> > not just "all you consider important").
>
> Note, the code is only invokved for systems where IEEE 128-bit floating point
> is supported. So it will never get called for a lot of the random embedded
> systems or the big endian systems.
Did I say that?
I meant what I *said*, not whatever you imagine I meant.
Segher
