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

Vincent Broman broman@spawar.navy....
Fri Apr 18 20:19:09 CDT 2008


I reported back on August 30 to this list, 
with some discussion following on September 4 and 5,
about my attempt to build numpy on an ancient powerpc setup.
I'm running yellow dog linux 2.1, gcc 2.95.3.20010111, on processors from Curtiss-Wright Controls.
Don't tell me to just upgrade; this configuration will be 
fighting the good fight for several more years.
I just retried with the latest numpy (svn yesterday) and gotten further than I did before.

umathmodule.c gets many compiler errors from gcc, of two kinds.

The simpler were like

    warning: conflicting types for built-in function `sinl'

repeated for `cosl', `fabsl', and `sqrtl'.
These seem to be caused by npy_longdouble being typedef'ed as double not long double,
due to the latter two types having the same size.
umathmodule.c defines its own sinl, sqrtl, etc. with npy_longdouble arguments and results,
which then conflict with the builtin sinl, sqrtl provided by gcc that expect long double.
I worked around that by adding the "-fno-builtin" argument to the extra_compiler_args in setup.py.

The other compiler complaints from the same file were:

    inconsistent operand constraints in an  `asm'

which came from every line that raised a division by zero exception,
the code in each case being "feraiseexcept( FE_DIVBYZERO)" after preprocessing.
That function is defined in fenv.h with a "__THROW" attribute,
but I saw no sign of it being an inline asm or anything.
I don't understand "__THROW".

I'm afraid I would need to find the asm code involved, before I could
see what "operand constraints" are "inconsistent".
Any hints where to look?
Any way to make the call go to a nice simple library instead?

Vincent Broman


More information about the Numpy-discussion mailing list