This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: tst-strtod-round.c build failure on ARM
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Fri, 12 Sep 2014 17:18:46 +0000
- Subject: Re: tst-strtod-round.c build failure on ARM
- Authentication-results: sourceware.org; auth=none
- References: <CANu=Dmj4N5FKt7bVceWowy=iG3if7VM_2ZudA-fvuy2WZEw9oQ at mail dot gmail dot com>
On Fri, 12 Sep 2014, Will Newton wrote:
> The failure is caused by the implicit function declaration now being
> treated as an error. math.h is included in tst-strtod-round.c for
> copysignl but the declaration of copysignl is guarded with the
> following conditional in math/math.h:
>
> # if !(defined __NO_LONG_DOUBLE_MATH && defined _LIBC) \
> || defined __LDBL_COMPAT
>
> On ARM __LDBL_COMPAT is not defined (I am not sure where it ever gets
> defined), but __NO_LONG_DOUBLE_MATH is and _LIBC is defined by
> libc-symbols.h, which is explicitly included on the command line by
> Makeconfig.
>
> Does anybody know what the correct fix for this would be? It seems
> strange to define _LIBC for test code but it looks like it is required
> by some tests.
I think the following principles apply on systems where long double has
the same representation and alignment as double:
* In some cases, it is not possible, or at least not convenient, to
declare the long double functions as usual in the headers, because they
get defined as aliases to the double functions, which would result in
errors for incompatible types if the normal declarations were present - I
haven't tested it, but suppose this is why the existing _LIBC conditional
is present. (There are ways to work around this, but the normal glibc
macros for creating aliases use typeof in a way that gets errors if the
types don't match.)
* It is desirable to test the long double aliases on the general principle
that they are public interfaces and all public interfaces should be
tested. (Although testing them won't provide much extra code coverage in
the testsuite, just coverage of different symbol names for the same
entry points.)
* Most tests should ideally be built and tested in an environment as
similar as possible to that used for normal user programs built with glibc
(which would mean using a sysroot with installed headers and libraries,
without search paths that find any of the internal headers from the glibc
source tree, as well as not using _LIBC to build tests). Actually getting
there from where we are now is probably hard. And some tests do have good
reason to use internal headers - for example, there are tests that verify
correct functioning of internal headers, so that problems with those
headers show up in a way that's easier to debug than for a more indirect
test of the functionality using that header (e.g. csu/tst-atomic,
stdlib/tst-tininess).
Given those principles, I suggest making the installed header test
_LIBC_TEST and declare the functions if that's defined, and making the
test define _LIBC_TEST before including system headers. Cf.
sysdeps/arm/fpu_control.h testing of _LIBC_TEST. (But whereas there's an
ARM wrapper for test-fpucw.c, in the present case the suggested header
change is architecture-independent, and so the suggested testcase change
is also architecture-independent. This applies to all architectures where
double and long double have the same representation and alignment.)
--
Joseph S. Myers
joseph@codesourcery.com