On Thu, Jun 12, 2014 at 01:53:16PM -0400, Tim Prince wrote:
I'm still looking for an answer about why round_4.f90 is made to fail
due to the undefined reference nextafterl(). If this is considered as
a failure of libquadmath, shouldn't libquadmath provide that function
when it isn't in the C library? Otherwise, it seems an expected fail of
libquadmath for any newlib target. A web search hints that it depends
in newlib on _LDBL_EQ_DBL i.e. in effect:
#ifdef _LDBL_EQ_DBL
#define nextafterl(x,y) nextafter(x,y)
#endif
which I doubt would be compatible with libquadmath.
Don't know how it works on cygwin64, but "long double" on
most x86_64 based systems maps to the 80-bit Intel extended
precision format (aka REAL(10)). The functions in libquadmath
map to an IEEE 128-bit floating point format (aka REAL(16)).
If your system supports the 80-bit Intel format, then your
system's libm should provide nextafterl() for REAL(10)
and libquadmath should provide a version of nextafter for
REAL(16). For example, on x86_64 FreeBSD
% nm /usr/lib/libm.a | grep nextaf
s_nextafterf.o:
0000000000000000 T nextafterf
s_nextafterl.o:
0000000000000000 T nextafterl
s_nextafter.o:
0000000000000000 T nextafter
% nm /usr/home/sgk/work/4x/lib/libquadmath.a | grep nextaf
nextafterq.o:
0000000000000000 T nextafterq