This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug math/19270] New: Shared libm missing __isnanl
- From: "danglin at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 20 Nov 2015 00:50:48 +0000
- Subject: [Bug math/19270] New: Shared libm missing __isnanl
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=19270
Bug ID: 19270
Summary: Shared libm missing __isnanl
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: math
Assignee: unassigned at sourceware dot org
Reporter: danglin at gcc dot gnu.org
CC: deller at gmx dot de
Target Milestone: ---
Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
Build: hppa-unknown-linux-gnu
This issue causes a build failure for various debian packages including gmt:
/usr/bin/cc -std=gnu99 -fstrict-aliasing -g -O2 -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2 -fopenmp -O2 -g -DNDEBUG -fopenmp
CMakeFiles/gmt.dir/gmt.c.o -o gmt -rdynamic libgmt.so.5.2.1 -lnetcdf
/usr/lib/hppa-linux-gnu/hdf5/ser
ial/libhdf5_hl.so /usr/lib/hppa-linux-gnu/hdf5/serial/libhdf5.so -lpthread -ldl
-lm -lcurl -lgdal -lpcre -lfftw3f -lfftw3f_threads -llapack -lblas
libpostscript
light.so.5.2.1 -lz -lm -ldl
-Wl,-rpath,/home/dave/debian/gmt/gmt-5.2.1+dfsg/debi
an/build/src:/usr/lib/hppa-linux-gnu/hdf5/serial:
libgmt.so.5.2.1: undefined reference to `__isnanl'
We have in math.h:
* Return nonzero value if X is a NaN. We could use `fpclassify' but
we already have this functions `__isnan' and it is faster. */
# ifdef __NO_LONG_DOUBLE_MATH
# define isnan(x) \
(sizeof (x) == sizeof (float) ? __isnanf (x) : __isnan (x))
# else
# define isnan(x) \
(sizeof (x) == sizeof (float) \
? __isnanf (x) \
: sizeof (x) == sizeof (double) \
? __isnan (x) : __isnanl (x))
# endif
We have in mathdef.h:
/* On hppa `long double' is 64-bits. */
#undef __NO_LONG_DOUBLE_MATH
We have from s_isnan.c:
#undef __isnan
int
__isnan (double x)
{
int32_t hx, lx;
EXTRACT_WORDS (hx, lx, x);
hx &= 0x7fffffff;
hx |= (u_int32_t) (lx | (-lx)) >> 31;
hx = 0x7ff00000 - hx;
return (int) (((u_int32_t) hx) >> 31);
}
hidden_def (__isnan)
weak_alias (__isnan, isnan)
#ifdef NO_LONG_DOUBLE
strong_alias (__isnan, __isnanl)
weak_alias (__isnan, isnanl)
#endif
We have from math/Makefile:
ifneq ($(long-double-fcts),yes)
# The `double' and `long double' types are the same on this machine.
# We won't compile the `long double' code at all. Tell the `double' code
# to define aliases for the `FUNCl' names. To avoid type conflicts in
# defining those aliases, tell <math.h> to declare the `FUNCl' names with
# `double' instead of `long double'.
math-CPPFLAGS += -DNO_LONG_DOUBLE -D_Mlong_double_=double
endif
Since double and long double are both 64-bits, the above is selected and
s_isnanf.c is built with NO_LONG_DOUBLE defined. This yields the following
aliases with gcc-5:
extern __typeof (__isnan) __EI___isnan __asm__("" "__isnan"); extern __typeof
(__isnan) __EI___isnan __attribute__((alias ("" "__GI___isnan")));
extern __typeof (__isnan) isnan __attribute__ ((weak, alias ("__isnan")));
extern __typeof (__isnan) __isnanl __attribute__ ((alias ("__isnan")));
extern __typeof (__isnan) isnanl __attribute__ ((weak, alias ("__isnan")));
This results in following assembly code:
.cfi_startproc
__GI___isnan:
.PROC
.CALLINFO FRAME=0,NO_CALLS
.ENTRY
.LVL0:
.LBB2:
.loc 1 30 0
fstds %fr5,-16(%sp)
ldws -16(%sp),%r28
ldws -12(%sp),%r29
.LVL1:
.LBE2:
.loc 1 31 0
extru %r28,31,31,%r20
.loc 1 32 0
sub %r0,%r29,%r21
or %r21,%r29,%r28
.LVL2:
extru %r28,0,1,%r28
or %r28,%r20,%r28
.LVL3:
.loc 1 33 0
ldil L'2146435072,%r20
sub %r20,%r28,%r28
.LVL4:
.loc 1 35 0
bv %r0(%r2)
extru %r28,0,1,%r28
.EXIT
.PROCEND
.cfi_endproc
.LFE16:
.size __GI___isnan, .-__GI___isnan
.globl __isnan
.set __isnan,__GI___isnan
.weak isnan
.set isnan,__isnan
.globl __GI___isnanl
.hidden __GI___isnanl
.set __GI___isnanl,__isnan
.weak isnanl
.set isnanl,__isnan
As can be seen, we end up with hidden symbol __GI___isnanl aliased to __isnan
and the is no __isnanl symbol.
Probably, __NO_LONG_DOUBLE_MATH was not defined at a time when NO_LONG_DOUBLE
didn't exist and the long double routines were all compiled. Now it probably
should be defined.
Bug is known to exist in 2.19 and later.
--
You are receiving this mail because:
You are on the CC list for the bug.