On Tue, Dec 27, 2011 at 6:52 AM, Dominique Dhumieres <domi...@lps.ens.fr> 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). >
That is correct. -fdefault-real-8 provides a finely tuned type promotion mechanism, while -freal-*-real-* overrides all type definitions via brute force. We actually like that: some of the codes we have date back to the 70's, we don't want to convert them into Fortran 95 and/or maintain several copies with different type definitions - this is just too expensive and time consuming. In such cases, we really do want to override all old-style definitions. In our work, this doesn't happen often, usually, we are running our code in double precision, but from time to time we would like to raise precision to pre-compute tables with more digits or to investigate ill-conditioning and numerical stability issues. > 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) ... > > 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. > We do recompile all codes with the promotion flags to address this, usually, with only minor modifications. Things like calls to external C functions need to be fixed, although this is also needed if using -fdefault-* flags. Alignment could be also a problem, especially if promoting to quad precision which currently requires 128-bit variable aligment, again this also might also happen with -fdefault-* flags. The user has to be somewhat aware of this and adjust the code accordingly. We tend to ignore such issues in practice and proceed anyway with fingers crossed: everything works 90% of the time just fine! Zydrunas
