fortran-dev issues (cygwin64)

[Tim Prince]

On 6/12/2014 2:31 PM, Steve Kargl wrote:
> 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
So it appears these tests are made to fail (in both selected data types) 
due to lack of provision by newlib of a nextafterl() to support real(10).
$ nm /usr/lib/libm.a|grep nextafter
                  U __imp_nextafter
0000000000000000 T nextafter
                  U __imp_nextafterf
0000000000000000 T nextafterf

$ nm /usr/local/fd/lib/libquadmath.a|grep nextafter
nextafterq.o:
0000000000000000 T nextafterq

As you say, the real(10) support might be supplied by adding a BSD 
source code for nextafterl().  newlib has been adding some long double 
(x87) support over the last decade but it is far from complete.
Thanks for confirming that this is considered a separate question from 
libquadmath, although the test suite insists on failing if only one is 
missing.

-- 
Tim Prince