[Numpy-discussion] Solaris Sparc build broken

Michael Droettboom mdroe@stsci....
Thu Nov 12 08:34:45 CST 2009


The new macros contain non-constant initializers for a type declared 
constant.

    const union IEEEl2bitsrep u = {x};

AFAIK, ANSI dictates that the initializer must be a literal or another 
constant variable.  We could declare 'x' as constant in the function 
signature, but it actually does get changed in the body of the function.

cc: acomp failed for 
build/src.solaris-2.8-sun4u-2.5/numpy/core/src/npymath/ieee754.c
"numpy/core/src/npymath/ieee754.c.src", line 166: warning: non-constant 
initializer: op "NAME"
"numpy/core/src/npymath/ieee754.c.src", line 166: left operand must be 
modifiable lvalue: op "="
"numpy/core/src/npymath/ieee754.c.src", line 167: warning: non-constant 
initializer: op "NAME"
"numpy/core/src/npymath/ieee754.c.src", line 167: left operand must be 
modifiable lvalue: op "="
"numpy/core/src/npymath/ieee754.c.src", line 168: warning: non-constant 
initializer: op "NAME"
"numpy/core/src/npymath/ieee754.c.src", line 168: left operand must be 
modifiable lvalue: op "="
"numpy/core/src/npymath/ieee754.c.src", line 169: warning: non-constant 
initializer: op "NAME"
"numpy/core/src/npymath/ieee754.c.src", line 169: left operand must be 
modifiable lvalue: op "="
"numpy/core/src/npymath/ieee754.c.src", line 171: warning: non-constant 
initializer: op "NAME"
"numpy/core/src/npymath/ieee754.c.src", line 171: left operand must be 
modifiable lvalue: op "="
"numpy/core/src/npymath/ieee754.c.src", line 172: warning: non-constant 
initializer: op "NAME"
"numpy/core/src/npymath/ieee754.c.src", line 172: left operand must be 
modifiable lvalue: op "="
"numpy/core/src/npymath/ieee754.c.src", line 173: warning: non-constant 
initializer: op "NAME"
"numpy/core/src/npymath/ieee754.c.src", line 173: left operand must be 
modifiable lvalue: op "="
"numpy/core/src/npymath/ieee754.c.src", line 174: warning: non-constant 
initializer: op "NAME"
"numpy/core/src/npymath/ieee754.c.src", line 174: left operand must be 
modifiable lvalue: op "="

I replaced:

   const union IEEEl2bitsrep u = {x};

with

   union IEEEl2bitsrep u; u.e = x;

Hopefully a good compiler optimizer will alias this away.  
Alternatively, we could do what C++ would call a "reinterpret cast", 
which would avoid the need for the "do { ... } while (0);" trick:

   ((IEEEl2bitsrep *)(&(x)))->a

Also, it seems LDBL_NBIT wasn't defined for the 
HAVE_LDOUBLE_IEEE_QUAD_BE case:

   "numpy/core/src/npymath/ieee754.c.src", line 176: undefined symbol: 
LDBL_NBIT

I defined it as 0.  Is that correct?

So that got it to compile.  Unfortunately, then I run into assertion 
errors in the unit test:

 > /home/mdroe/numpy/numpy/core/tests/test_umath.py(834)test_nextafter()
-> assert np.nextafter(one, two) - one == eps
(Pdb) p t
<type 'numpy.float128'>
(Pdb) p eps
1.9259299443872358531e-34
(Pdb) p np.nextafter(one, two)
1.0
(Pdb) p np.nextafter(one, two) - one
0.0
(Pdb) p (np.nextafter(one, two) - one) == 0.0
True

It looks as if the nextafterl implementation isn't ever packing fields 
back into the long double at all.  I can confirm this error even when 
using the numpy nextafterl on x86 Linux with gcc (by undef'ing 
HAVE_NEXTAFTERL on that platform).

Take for example the following block:

    if (x == 0.0) {
        xmanh = 0;              /* return +-minsubnormal */
        xmanl = 1;
        xsign = ysign;
        t = x * x;
        if (t == x) {
            return t;
        } else {
            return x;           /* raise underflow flag */
        }
    }

'xmanh', 'xmanl' and 'xsign' are completely disconnected variables from 
the original long double 'x'.  It seems the function needs to be written 
in terms of both getter and setter macros for each of the fields (as in 
my patch from yesterday), or it needs a macro re-pack the fields, e.g.

   LDOUBLE_PACK(x, sign, exp, manh, manl)

which could be inserted before the "t = x * x" line above.  Personally, 
I think the getter/setter approach is cleaner, even if more verbose, 
because it's not otherwise terribly obvious when the value needs to be 
re-packed.

I'm happy to make these changes, since I've got access to the "finicky" 
platform, but want to confirm how you would prefer it done first.

Mike

David Cournapeau wrote:
> On Thu, Nov 12, 2009 at 12:45 AM, David Cournapeau <cournape@gmail.com> wrote:
>
>   
>> I will implement this, but I would prefer using this method everywhere
>> for every compiler, it would be more robust.
>>     
>
> Done for r7727. I have not tested it much (I have only checked that
> the bit twiddling macros to get sign/exp/mantissa works as expected on
> sparc linux).
>
> David
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA



More information about the NumPy-Discussion mailing list