[Numpy-discussion] Solaris Sparc build broken
Wed Nov 11 09:33:59 CST 2009
Thanks. Behind that, however, it runs into this compiler shortcoming:
"numpy/core/src/npymath/npy_math_private.h", line 229: invalid type for bit-field: manh
"numpy/core/src/npymath/npy_math_private.h", line 230: invalid type for bit-field: manl
It seems that Sun compilers (before Sun Studio 12, C compiler 5.9),
don't support bit fields larger than 32-bits. Welcome to my world :)
You can see a discussion of this here:
and the release notes for Sun C compiler 5.9 here:
The best solution I've been able to dream up is to use a macro to get at
the manh bitfield on these older compilers. This fix does seem to pass
the "test_umath.py" unit tests. It's not as clean as the bit-field
method, but it should be more portable. You can see what I'm getting at
in the attached (rough) patch.
Can you think of a better solution? If this is *the* solution, we may
want to add getters/setters for all the members (sign, exp, manl) and
fix nextafterl in terms of those, just for consistency.
David Cournapeau wrote:
> On Wed, Nov 11, 2009 at 6:18 AM, Michael Droettboom <email@example.com> wrote:
>> I don't know if your 'long double' detection code is complete yet, but I
>> thought I'd share the current build output on one of our Solaris
>> machines. It looks like it may just be a typo difference between
>> 'IEEE_QUAD_BE' in long_double_representation() and 'IEEE_QUAD_16B_BE' in
>> setup.py, but I wanted to confirm.
> Yes, you're right - I don't have any machine with a 128 bits long
> double type, so I let the typo slipped.
> Could you try last revision (r7726) ?
> NumPy-Discussion mailing list
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
More information about the NumPy-Discussion