Re: [PATCH] nldbl-compat.c: Include math.h before nldbl-compat.h.

[Zack Weinberg <zackw at panix dot com>]

On Mon, Mar 12, 2018 at 8:47 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Sun, 11 Mar 2018, Zack Weinberg wrote:
>
>> Jeff Law noticed that native PowerPC builds were broken by my having
>> made math_ldbl_opt.h not include math.h.  nldbl-compat.c formerly got
>> math.h via libioP.h and math_ldbl_opt.h, *without* __NO_LONG_DOUBLE_MATH;
>> after my change it got it via nldbl-compat.h *with* __NO_LONG_DOUBLE_MATH,
>> but __NO_LONG_DOUBLE_MATH mode is forbidden on hosts that define
>> __HAVE_DISTINCT_FLOAT128, so the build breaks.  I don't know why this
>> didn't come up in a build-many-glibcs cycle.
>
> It did, with GCC mainline (older GCC doesn't default to supporting
> _Float128 on powerpc64le but only supports it when certain options are
> passed).

Oh, OK.  I used the defaults, which are still 7.3.

When you get around to it, it sure would be nice if your buildbot
would post links to logs for failing builds.  I didn't see that
message, but given only its contents I would have assumed it wasn't my
mistake.

>> I pushed this as a quick fix, but there's a deeper problem: presumably
>> nldbl-compat.h defines __NO_LONG_DOUBLE_MATH for a reason, but if we
>
> To disable long double function declarations, so that e.g. nldbl-sin.c can
> define sinl with the "wrong" type (but the type correct for the ABI for
> which it's being built).

Hmm.  I _think_ nldbl-compat.c doesn't need to define any names from
math.h.  So we should be OK with the status quo for now.

> The files such as nldbl-sin.c are for libnldbl_nonshared.a, which
> supposedly supports -mlong-double-64 with compilers not supporting asm
> redirection (if asm redirection is supported, it's used so that calls to
> sinl etc. call sin etc. in that case).  I suspect in fact this case hasn't
> worked for a long time

I would back an official policy change that starting with version N we
will only support compilers for which __REDIRECT can be implemented
_somehow_ (not necessarily just compilers for which the GNU definition
of __REDIRECT works, but that's the only definition we have right now,
patches welcome).  That would cut a great deal of questionable cruft
out of public headers.  It might mean we can't support that Compaq
compiler in the message you referenced, but I doubt anyone would mind
at this point.

zw