This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [www-patch] bugs.html rewrite,part 2: revamp floating point section


On 18 Aug, Bradley Lucier wrote:
> Re:
> 
>> +<p>On some architectures calculations inside the floating point unit 
>> (FPU)
>> +are done with higher precision than memory operations like storing 
>> floating
>> +point numbers (e.g., a <code>double</code> has 80 bits in the FPU on 
>> x86,
>> +but only 64 bits in memory). Thus, writing data to memory involves 
>> rounding!
>> +That's why the following C program might print <code>"Uh 
>> oh!"</code>.</p>
>> +<blockquote><pre>
>> +int main()
>> +{
>> +  double          x=sqrt(2.0);
>> +  volatile double y=x;
>> +  if (x!=y) printf("Uh oh!\n");
>> +  return 0;
>> +}
>> +</pre></blockquote>
>> +
>> +<p>Again, this is not a bug in the compiler, but a result of rounding
>> +(in conjunction with the excess precision of the FPU).</p>
> 
> I would claim that this *is* a bug in the compiler, but it's one that's 
> extremely unlikely to be fixed in the foreseeable future, and we've 
> rehashed this all before.

I'd claim that the compiler is allowed to round or not to round floating
point numbers whenever it pleases. This includes comparisons and memory
operations.

> Why not try
> 
>> +<blockquote><pre>
>> +int main()
>> +{
>> +  volatile double y=sqrt(2.0);
>> +  if (sqrt(2.0)!=y) printf("Uh oh!\n");
>> +  return 0;
>> +}
>> +</pre></blockquote>

The point of my example was to show that the mere storage operation
causes rounding. This isn't that obvious with your example, where the
same calculation is done twice (one could think it's the calculation
that causes the different results - and miss the whole point).

The fact that you consider the first example buggy, IMHO shows that
it should be formulated this way: It really shows the most extreme
(and counter-intuitive) consequences of the rounding rules.

> Then I think we would both agree that if the programmer didn't expect 
> "Uh oh!" to be printed, then their expectations need to be realigned on 
> the x86.

Good formulation. ;-)

> Brad

Regards,
Volker



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]