I've pushed in pure implementations of functions in std.math,
removing the workaround in core.stdc.math.
This passes for x64/x32. Can any ARM testers please report any
problems causecd by this update?
Thanks
Iain.

I've pushed in pure implementations of functions in std.math,
removing the workaround in core.stdc.math.
This passes for x64/x32. Can any ARM testers please report any
problems causecd by this update?
Thanks
Iain.

I've pushed in pure implementations of functions in std.math,
removing the workaround in core.stdc.math.
This passes for x64/x32. Can any ARM testers please report any
problems causecd by this update?
Thanks
Iain.

Compiling phobos fails with this message:
../../../../gcc-4.8.1/libphobos/src/std/math.d:3264: Error: static
assert "Only 80-bit and 96-bit reals are supported by lrint()"
real is 64 bit on most (all?) ARM machines.
I also started the compiler test suite some time ago but it will take
some more time till it's finished.

I've pushed in pure implementations of functions in std.math,
removing the workaround in core.stdc.math.
This passes for x64/x32. Can any ARM testers please report any
problems causecd by this update?
Thanks
Iain.

Compiling phobos fails with this message:
../../../../gcc-4.8.1/libphobos/src/std/math.d:3264: Error: static
assert "Only 80-bit and 96-bit reals are supported by lrint()"
real is 64 bit on most (all?) ARM machines.
I also started the compiler test suite some time ago but it will take
some more time till it's finished.

I've pushed in pure implementations of functions in std.math,
removing the workaround in core.stdc.math.
This passes for x64/x32. Can any ARM testers please report any
problems causecd by this update?
Thanks
Iain.

Compiling phobos fails with this message:
../../../../gcc-4.8.1/libphobos/src/std/math.d:3264: Error: static
assert "Only 80-bit and 96-bit reals are supported by lrint()"
real is 64 bit on most (all?) ARM machines.
I also started the compiler test suite some time ago but it will take
some more time till it's finished.

I've pushed in pure implementations of functions in std.math,
removing the workaround in core.stdc.math.
This passes for x64/x32. Can any ARM testers please report any
problems causecd by this update?
Thanks
Iain.

I found a bug in the floor implementation for 64 bit reals:
int exp = (vu[F.EXPPOS_SHORT] & 0x7ff) - 0x3ff;
The constants are wrong: At least 0x7ff must be 0x7ff0.
(Remember, the 16 bits are s|eeeeeeeeeee|???? )
However, the results are still wrong and I don't really understand how
that equation should work.
The 'naive' and working way to write this is
--------
int exp = ((vu[F.EXPPOS_SHORT] & 0x7ff0) >> 4) -1023;
--------
I assume 0x3ff should be changed to 0x3ff0 which is 1023 << 4. But then
the result is still left-shifted by 4 and needs to be right-shifted:
-------
int exp = (((vu[F.EXPPOS_SHORT] & 0x7ff0)) - 0x3ff0) >> 4;
-------
is also working, but I don't know what's the advantage of this version.
floatTraits also has EXPBIAS = 0x3f_e_0? How was that value obtained?

I've pushed in pure implementations of functions in std.math,
removing the workaround in core.stdc.math.
This passes for x64/x32. Can any ARM testers please report any
problems causecd by this update?
Thanks
Iain.

I found a bug in the floor implementation for 64 bit reals:
int exp = (vu[F.EXPPOS_SHORT] & 0x7ff) - 0x3ff;
The constants are wrong: At least 0x7ff must be 0x7ff0.
(Remember, the 16 bits are s|eeeeeeeeeee|???? )
However, the results are still wrong and I don't really understand how
that equation should work.
The 'naive' and working way to write this is
--------
int exp = ((vu[F.EXPPOS_SHORT] & 0x7ff0) >> 4) -1023;
--------
I assume 0x3ff should be changed to 0x3ff0 which is 1023 << 4. But then
the result is still left-shifted by 4 and needs to be right-shifted:
-------
int exp = (((vu[F.EXPPOS_SHORT] & 0x7ff0)) - 0x3ff0) >> 4;
-------
is also working, but I don't know what's the advantage of this version.
floatTraits also has EXPBIAS = 0x3f_e_0? How was that value obtained?

I've pushed in pure implementations of functions in std.math,
removing the workaround in core.stdc.math.
This passes for x64/x32. Can any ARM testers please report any
problems causecd by this update?
Thanks
Iain.

I found a bug in the floor implementation for 64 bit reals:
int exp = (vu[F.EXPPOS_SHORT] & 0x7ff) - 0x3ff;
The constants are wrong: At least 0x7ff must be 0x7ff0.
(Remember, the 16 bits are s|eeeeeeeeeee|???? )
However, the results are still wrong and I don't really understand how
that equation should work.
The 'naive' and working way to write this is
--------
int exp = ((vu[F.EXPPOS_SHORT] & 0x7ff0) >> 4) -1023;
--------
I assume 0x3ff should be changed to 0x3ff0 which is 1023 << 4. But then
the result is still left-shifted by 4 and needs to be right-shifted:
-------
int exp = (((vu[F.EXPPOS_SHORT] & 0x7ff0)) - 0x3ff0) >> 4;
-------
is also working, but I don't know what's the advantage of this version.
floatTraits also has EXPBIAS = 0x3f_e_0? How was that value obtained?

I've pushed in pure implementations of functions in std.math,
removing the workaround in core.stdc.math.
This passes for x64/x32. Can any ARM testers please report any
problems causecd by this update?
Thanks
Iain.

I've pushed in pure implementations of functions in std.math,
removing the workaround in core.stdc.math.
This passes for x64/x32. Can any ARM testers please report any
problems causecd by this update?
Thanks
Iain.

Make Don aware of this. But looks ok to me. Does it fail in the same
way for double on x86/x86_64?

If I modify frexp to use double instead of real it also fails on
x86 in the same way:
http://dpaste.dzfl.pl/72725240
But the double code path is not used on x86. x86 always uses the real
version and therefore doesn't show this issue. I'll file a pull request
on github and ping Don about this.