[Bug target/34261] Directed rounding doesn't work on MacOS X

["pinskia at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #3 from pinskia at gcc dot gnu dot org  2007-11-30 22:20 -------
(In reply to comment #2)
> In a strict sense maybe not. fprintf() in GCC works fine on other  
> Unix-based systems. The trouble would be that GCC's communication  
> with the OS kernel somehow screwed up on this particular system. So  
> you can blame the kernel, not GCC. This is way beyond my capability  
> as a user to fix or even understand, so I have to rely on you experts  
> to fix it.

Lets put it this way.  If fprintf failed, it does not mean it is a GCC bug as
GCC does not provide the fprintf library function.  Yes GCC could have an ABI
bug but that would mean everything else would be broken but since just fprintf
is broken, it is most likely a bug in fprintf.

> Interval arithmetic IA is in a unique position. It *also* relies on a  
> basic and simple communication with the OS, namely the ability to  
> switch rounding mode. If you can do this, your IA software works. If  
> you can't, it doesn't.

Well since fesetround is not provided by GCC, it is provided by the system. 
Also are you using Apple's provided GCC, if so please file a bug with them.  We
cannot support their modified version anyways.

> This violates the IEEE754 standard, which of course mandates rounding to
> nearest as the default.

Of course x87 violates it anyways.

When I ran the test on a x86 machine, I get:
apinski@debian:~$ ./a.out 1 3
fesetround(0) returned 0
Then fegetround() returned 0
fesetround(1) returned 1
Then fegetround() returned 0
fesetround(2) returned 1
Then fegetround() returned 0
fesetround(3) returned 1
Then fegetround() returned 0
z0=0.333333333333333315, z1=0.333333333333333315, z2-z1=0, z1-z3=0



But when I run it on a PowerPC machine (which does not violate the IEEE
standard):
fesetround(0) returned 0
Then fegetround() returned 0
fesetround(1) returned 0
Then fegetround() returned 1
fesetround(2) returned 0
Then fegetround() returned 2
fesetround(3) returned 0
Then fegetround() returned 3
z0=0.333333333333333315, z1=0.333333333333333315, z2-z1=5.55112e-17, z1-z3=0


So I think this is just an x87 issue of execusive precission.

Please read bug 323.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34261