Re: [COMMITTED] tile: define __NO_LONG_DOUBLE_MATH

[Chris Metcalf <cmetcalf at ezchip dot com>]

On 11/24/2015 5:41 PM, Joseph Myers wrote:
> On Tue, 24 Nov 2015, Chris Metcalf wrote:
>
> > This avoids build failures in the tests, and matches what is in
> > bits/mathdef.h.
> >
> > Update the libc and libm abilist files to include __finitel,
> > __isinfl, and __isnanl.
> The abilist changes need more explanation.  Did you previously have ABI
> test failures for the baselines being incorrect?  How did such incorrect
> baselines arise?

No, there were no previous ABI test failures.  They were correct before, since without
__NO_LONG_DOUBLE_MATH, those functions are hidden (see include/math.h).
I added that define because I was getting new build failures on some signgam
tests without it, something like these:

https://sourceware.org/ml/libc-alpha/2015-11/msg00172.html

I noticed that every other platform defined that macro except hppa. And since
every platform except hppa seems to export __isinfl and friends, adding it to the
tile ABI list seemed like the right fix.  This fix is also due to my seeing references
to bug 19270 and a fix for hppa recently:

https://sourceware.org/bugzilla/show_bug.cgi?id=19270
https://sourceware.org/ml/libc-alpha/2015-11/msg00520.html

> Were the symbols in fact exported at version GLIBC_2.12
> in the binaries of that version that were the reason for starting symbols
> at that version rather than 2.15?  Unless those 2.12 binaries had these
> symbols, they should not be exported at version GLIBC_2.12.  You could add
> them to GLIBC_2.23 for tile, but really there should be no need for those
> symbols at all in the __NO_LONG_DOUBLE_MATH case so the only case for
> doing so would be consistency between architectures; it would be better
> for the preferred approach to be that these symbols aren't exported in
> that case, as with __issignalingl, with backwards compatibility only for
> existing such architectures that export them.  (The public interfaces
> finitel, isinfl, isnanl of course should be exported as they already were
> - although as legacy interfaces no new versions of them should be added
> for TS 18661-3 types, only versions such as __isnanf128 when actually
> needed.)

Yes, I agree that exporting them seems pointless, but every other architecture does
as well, so it seemed uncontroversial.  And I only chose 2.12 on the theory that they
should have been exported then.  I don't really care what version I export them as,
since there's really no way for userspace to generate a reference to them, since the
macrology in math/math.h can't generate a reference to them no matter whether
__NO_LONG_DOUBLE_MATH is defined or not.  Let me know if you have an idea for
what would be cleaner here and I am happy to make the change, but it does seem
like it should be a change for every platform without long double, not just tile.
Thanks!

--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com