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 <[email protected]> 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
> [email protected]
> 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
_______________________________________________
NumPy-Discussion mailing list
[email protected]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
