This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug math/19270] New: Shared libm missing __isnanl


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]