------- Comment #6 from rob1weld at aol dot com  2007-06-21 11:30 -------
Thanks for everyones input.


The only issues related to this 'bug' are:

1): printf _sometimes_ prints "-0.000" and sometimes prints "+0.000" - the
reason it is even showing the "+" or "-" is because I enabled them using "%+f",
this I understand. 

My 2 cents is that the correct answer is "+0.000" and never "-0.000" - UNLESS,
that is related to _accuracy_ and nothing to do with "printf"; in which cause
that is a different bug.


2): Using a "sprintf()" to print the answer to a char string (which itself is
never even used!) "fixes" the bug. This suggests to me that something is
upsetting the folding. It can't be an optimization issue since this occurs at
any optimization level (even -O0, none) so unless it is the parsing it may be
the folding.

Sometimes GCC goes "crazy" (see 6, 8, and 9). If indeed GCC is operating
"correctly" it should do the SAME thing everytime - Correct ?

If GCC want to convert it to an INT, fine. the correct answer is ZERO and not:
a): -16522743262502092537856.000
b): +60316137357217275485696900081464849817...(many more digits)...
c): -25531721305534761946185249871767754587...(many more digits)...

Cygwin gives the same (ridiculous) answer _everytime_ which is better though it
ought to be ZERO.

If GCC thinks it is doing the correct thing (there is NO BUG) then why doesn't
it do the SAME thing - it is saying that the previous time it was wrong and
wants to give a different answer, when it ought to give the same answer.

3): If this belongs on http://gcc.gnu.org/bugs.html#nonbugs then this is a
documentation bug.

Thanks for considering this report.


-- 


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

Reply via email to