Re: tst-strtod-round.c build failure on ARM

["Joseph S. Myers" <joseph at codesourcery 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