Re: [patch] Flag-controlled type conversions/promotions

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

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