Perhaps the title should mention that this is 32-bit x86, which is rather obsolete. This should work okay on x86_64.
Why would there be any difference?
GNU GCC does not round floating-point divisions to the nearest value
31–40 of 87 posts
Re: GNU GCC does not round floating-point divisions to the nearest value
#32x87 is crazy. Especially since you can’t easily know when something is truncated from 80 bits to 64. Add a parameter to a function and an unrelated calculation behaves differently because it now ran out of 80bit registers. Congratulations, you now have a spurious test failure you will spend weeks trying to find. The only way of doing FP on x86 and keeping your sanity is by making sure you use 32/64 bit floats 100% of…
Re: GNU GCC does not round floating-point divisions to the nearest value
#33Re: GNU GCC does not round floating-point divisions to the nearest value
#34x87 is crazy. Especially since you can’t easily know when something is truncated from 80 bits to 64. Add a parameter to a function and an unrelated calculation behaves differently because it now ran out of 80bit registers. Congratulations, you now have a spurious test failure you will spend weeks trying to find. The only way of doing FP on x86 and keeping your sanity is by making sure you use 32/64 bit floats 100% of…
Re: GNU GCC does not round floating-point divisions to the nearest value
#35Earlier quoted context omitted.
Are you sure? The FPU instruction set is the same.
The platform ABI can differ on the same cpu. I originally had the wrong answer here, but I'm including below for historical purposes and embarrassment. Re-reading on my laptop meant I didn't misread/read-the-expected? Basically by default when compiling for IA32 gcc assumes that there is no SSE unit, and so must use the x87 fpu. Alas the x87 unit doesn't have either 32 or 64 bit ieee floating point types, so the calc…
> The long double type uses a 15 bit exponent, a 64-bit mantissa with an explicit high order significant bit and an exponent bias of 16383.
So it is an 80-bit float.
Re: GNU GCC does not round floating-point divisions to the nearest value
#36Earlier quoted context omitted.
The platform ABI can differ on the same cpu. I originally had the wrong answer here, but I'm including below for historical purposes and embarrassment. Re-reading on my laptop meant I didn't misread/read-the-expected? Basically by default when compiling for IA32 gcc assumes that there is no SSE unit, and so must use the x87 fpu. Alas the x87 unit doesn't have either 32 or 64 bit ieee floating point types, so the calc…
Per the sysv abi[1] (bottom of page 11): > The long double type uses a 15 bit exponent, a 64-bit mantissa with an explicit high order significant bit and an exponent bias of 16383. So it is an 80-bit float. https://uclibc.org/docs/psABI-x86_64.pdf
For example on osx it is 80bit ieee, but on win64 it is a 64bit ieee.
That ABI difference means that having the same instruction set is not the only thing that matters.
Re: GNU GCC does not round floating-point divisions to the nearest value
#37Re: GNU GCC does not round floating-point divisions to the nearest value
#38x87 is crazy. Especially since you can’t easily know when something is truncated from 80 bits to 64. Add a parameter to a function and an unrelated calculation behaves differently because it now ran out of 80bit registers. Congratulations, you now have a spurious test failure you will spend weeks trying to find. The only way of doing FP on x86 and keeping your sanity is by making sure you use 32/64 bit floats 100% of…
The article is about 32 bit gcc. 64 bit gcc defaults to SSE, although you can force x87 if you want to. (although... maybe don't do that)
Re: GNU GCC does not round floating-point divisions to the nearest value
#39An example where this matters -- a new Mario 64 trick on the Virtual Console version because summing round-towards-zero numbers over a sine wave cycle produces a small delta which builds up over a couple of days to make a jump possible https://www.kotaku.com.au/2018/06/the-mario-64-trick-that-ta...
video games don't matter lol
Re: GNU GCC does not round floating-point divisions to the nearest value
#40An example where this matters -- a new Mario 64 trick on the Virtual Console version because summing round-towards-zero numbers over a sine wave cycle produces a small delta which builds up over a couple of days to make a jump possible https://www.kotaku.com.au/2018/06/the-mario-64-trick-that-ta...
> An example where this matters video games don't matter lol