The following code produces erroneous results with: GNU Fortran 95 (GCC 4.0.0 20041010 (experimental)) Copyright (C) 2003 Free Software Foundation, Inc. program real_test real(kind=4) :: little real(kind=8) :: big little=1.0/3.0 big=2.0/3.0 print *, little print *, big print *, '1/3 and 2/3?' end program real_test The output is: 0.3333333 0.666666686534882 1/3 and 2/3?
Confirmed, this is a front-end problem, we are not getting enough precission for some reason (really I don't know the rules of fortran). I will note the equivalent C code works just fine on the same build of the compiler so it is not a bug in the rest of GCC (aka fold and real.c).
gfortran uses its own constant folder, which uses the mpfr library. Apparently the precision is too low for double precision. Output from -fdump-parse-tree includes: ASSIGN big 6.66666686534882e-1_8 So it's indeed the frontend's fault.
Actually, looking at this again, gfortran's behavior is correct. If you had written big = 2.0_8 / 3.0_8 you would have gotten the result you were expecting. I think, adding a warning would be the best route for "fixing" this problem.
Subject: Re: Math error in simple divide operation On Mon, 2004-10-11 at 09:00, tobi at gcc dot gnu dot org wrote: > ------- Additional Comments From tobi at gcc dot gnu dot org 2004-10-11 16:00 ------- > Actually, looking at this again, gfortran's behavior is correct. > > If you had written > big = 2.0_8 / 3.0_8 > you would have gotten the result you were expecting. > > I think, adding a warning would be the best route for "fixing" this problem. I tried this same program with g95 before I submitted a bug and got what I thought was the correct results without needing the additional _8 . Do the standards specify that default precision for constants is kind=4? I suppose then that a warning would be good when mixing precisions in assignments.
(In reply to comment #4) > Subject: Re: Math error in simple divide operation > > I suppose then that a warning would be good when mixing precisions in > assignments. With Fortran 77, the great free tool ftnchek assisted in finding these problems and gave a warning that the r.h.s. result was promoted to a variable of higher precision. I am not aware of a similar free tool for Fortran 90. With the gfortran parser in place, this is a good opportunity to fill this gap. On the other hand, there are lots of real bugs waiting to be fixed... ;-)
(In reply to comment #4) > I tried this same program with g95 before I submitted a bug and got what > I thought was the correct results without needing the additional _8 . > Do the standards specify that default precision for constants is kind=4? Yes. A real constant is of type default real, if no kind suffix is given. Of course, the compiler is free to evaluate mathematical expressions any way it wants, as long as the result is a "mathematical approximation" to the expression, so g95 is not wrong. I assume that this difference between both compilers was added when Steve Kargl changed constant folding to use mpfr and the correct bit widths in all operations, a few months back. > I suppose then that a warning would be good when mixing precisions in > assignments. I agree, but I also agree with Harald Anlauf :-)
We actually do have a warning for this: -Wconversion, which is currently not enabled with -Wall. I'm closing this bug, but if you are in favor of adding this warning to -Wall, Jerry, feel free to propose a patch to this effect. See options.c.
Looks like I didn't close this bug, when I said I would.