http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #35 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-06-10 16:56:02 UTC --- (In reply to comment #33) > The last test case I am working is fmt_g0_6.f08. > > The apparent failing case is: > > print "(rc,g15.2)", 0.995000_8 > > Which is resulting in 0.99 and we expect it to be 1.0. > > However, the raw internal representation of 0.995 is not exact and is: > > 99499999999999999555 > > This places the value less then the threshold given in the table in the > Standard, giving the correct F format as: > > print "(f11.2,4x)", 0.995000_8 ! 0.99 > > Instead of > > print "(f11.1,4x)", 0.995000_8 ! 1.0 > > > Our F formatting in the test case is using the f11.1 and the logic does not > look at the third digit and dutifully rounds the value as it should. The new > G > formatting is using exact integer logic and dutifully does look at the third > digit. > > If we do: > > print "(rc,g15.2)", 0.9950001_8 > > The internal value does cross the 0.995 threshold and we do get the 1.0 > results. > > I think this issues is one of those splitting hairs things. We could > artificially round the digits string early before we process it, but this > would > effectively be rounding twice to get there. I would prefer to revise the test > case like so: > > call check_all(0.995000000001_RT, 15, 2, 0) > > and be done with this. The result is correct, but our expectation was wrong. 0.995000_8 which is internally 0.99499999999999999555... is smaller than 0.995 (exact value) so it must output 0.99, not 1.0. Please don't waste time with this test case (fmt_g0_6.f08), it is broken. I will fix this some time.
