On Tue, Dec 27, 2011 at 12:52:19PM +0100, Dominique Dhumieres wrote: > > -freal-4-real-8 is not equivalent to -fdefault-real-8 and > > -fdefault-double-8. > > > > -freal-4-real-8 interprets any 4-byte real type, whether it is a > > default real type or explicitly declared as 4-byte, as a 8-byte double > > precision type, and that applies to all variables, functions and > > constants. > > > > -fdefault-real-8 will promote only default real type to double > > precision and only variables and functions. Since constants are > > usually declared explicitly as 4-byte, e.g. 1.01223e0 is an explicitly > > defined 4-byte constant in gfortran, they will not be promoted. > > I agree with the above and I think this should go into the manual. One > thing which can be done with -fdefault-real-8, but not with > -freal-4-real-8 is to work around some pitfalls of these otions by > specifying explicit kinds when needed (this probably explains why less > tests fail with the former option than with the later, see results at the > end of this mail).
AFAICT, the whole point of these options is to promote everything, so one doesn't need to remember, for example, if literal constants, which are declarated with kind suffixes, are promoted or not. I don't see that as a pitfall. If one is testing the stability or accuracy of an algorithm, then promoting 'x = 1._4 / 1._4' may be important. Consider program k real x x = 1._4 / 3._4 end program k gfc4x -c -fdump-tree-original -fdefault-real-8 k.f90 real(kind=8) x; x = 3.333333432674407958984375e-1; gfc4x -c -fdump-tree-original -freal-4-real-8 k.f90 real(kind=8) x; x = 3.33333333333333314829616256247390992939472198486328125e-1; The difference is one heck of alot of ULPs. > In my opinion, these options, while useful, have several pitfalls: > > (1) call to external procedures (especially in libraries), > (2) alignements in EQUIVALENCE and/or COMMON, > (3) generic interfaces, > (4) BOZ, > (5) I/Os, > (6) ... One needs to worry about these things with the -fdefault-* options as well. In particular, anything that may depend on NUMERIC_STORAGE_SIZE will present a problem, because it is always set to 32 (except on a possibly pathological target without a 32-bit float type). > I wonder if they should not have their own page in the manual with a big > warning at the beginning telling the user that these options are likely to > break "legacy" codes. These options as well as the -fdefault-* are likely to break any Fortran code. It is up to the user to test whether these options are suitable for his/her purpose. I'll update the manual with a sentence of the form: "This option should be used with case and may not be suitable for codes. Inspection of the intermediate representation of the translated Fortran code, produced by the -fdump-tree-original option, is suggested." > === gfortran Summary for unix/-m32/-finteger-4-integer-8 === > > # of expected passes 37336 > # of unexpected failures 896 > # of expected failures 39 > # of unresolved testcases 1 > # of unsupported tests 570 > Well, I think you'll find a large number of these unexpected failures are due to hard coded assumptions about sizeof(INTEGER) etc. All of the failures I saw in gfortran.fortran-torture were of this variety. -- Steve
