This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: fortran-dev issues (cygwin64)
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: tprince at computer dot org
- Cc: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>
- Date: Thu, 12 Jun 2014 11:31:25 -0700
- Subject: Re: fortran-dev issues (cygwin64)
- Authentication-results: sourceware.org; auth=none
- References: <5399E90C dot 1060007 at aol dot com>
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
--
Steve