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

_______________________________________________

Numpy-discussion mailing list

[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion