[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.
#if NPY_SIZEOF_LONGDOUBLE == NPY_SIZEOF_DOUBLE
typedef double npy_longdouble;
#define NPY_LONGDOUBLE_FMT "g"
#else
typedef long double npy_longdouble;
#define NPY_LONGDOUBLE_FMT "Lg"
#endif
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.
------------------quote-------------------------------------------------
/* 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))
----------------endquote---------------------------------------------------
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