[Numpy-discussion] powerpc yellow dog linux port of numpy

Vincent Broman broman@spawar.navy....
Mon Apr 21 18:31:34 CDT 2008

I succeeded in working around the other Yellow Dog Linux porting problem 
connected with the floating point exception calls. 
It turns out that a problematic #include <bits/fenvinline.h> was protected
by a "#ifdef __OPTIMIZE__" so my preprocessing with "gcc -E" never saw its effect.
So, by avoiding optimization of umath, I was able to get a slower, but working copy 
of numpy compiled, which passed the numpy.test() suite.

The one-line patch avoiding my two compile problems 
adds to numpy/core/setup.py after line 270 the following line.

    extra_compile_args = ["-fno-builtin -O0"]

I don't know enough to say whether the quoted args should be split().

I do want to find real fixes, though, not just bandaids.

In numpy/core/include/numpy/ndarrayobject.h is code which causes me one problem.

        typedef double npy_longdouble;
        #define NPY_LONGDOUBLE_FMT "g"
        typedef long double npy_longdouble;
        #define NPY_LONGDOUBLE_FMT "Lg"

I do not see why the size is critical. Couldn't we just use long double
for any compiler that supports long double? If the double and long double
have the same format, why do we prefer double?

My other assembler code problem is caused, when optimization is enabled,
by code using the following definition in /usr/include/bits/fenvinline.h,
which I do not understand, never having done ppc assembler.

/* The weird 'i#*X' constraints on the following suppress a gcc
   warning when __excepts is not a constant.  Otherwise, they mean the
   same as just plain 'i'.  */

/* Inline definition for feraiseexcept.  */
# define feraiseexcept(__excepts) \
  ((__builtin_constant_p (__excepts) \
    && ((__excepts) & ((__excepts)-1) == 0 \
    && (__excepts) != FE_INVALID) \
   ? ((__excepts) != 0 \
      ? (__extension__ ({  __asm__ __volatile__ \
                           ("mtfsb1 %s0" \
                            : : "i#*X"(__builtin_ffs (__excepts))); \
                           0; })) \
      : 0) \
   : (feraiseexcept) (__excepts))

This definition causes all the occurences in umathmodule.c of

    feraiseexcept( FE_DIVBYZERO)

to make gcc complain of "inconsistent operand constraints in an  `asm'".
Is there anyone who can parse that hornet's nest of a definition?

Vincent Broman

More information about the Numpy-discussion mailing list