[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

["sgk at troutmask dot apl.washington.edu" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918

--- Comment #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Aug 30, 2021 at 10:26:59AM +0000, rimvydas.jas at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
> 
> --- Comment #7 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
> The suggested removal of -fdefault-real-8 -fdefault-double-8 options would be
> very problematic for many climate modeling libraries where similar '-r8' option
> works as users expect in different compilers: promoting only default types
> where no explicit kind is provided.  Often coupling interfaces between
> different climate modeling software libraries are already using explicit kinds
> for correct data passing, while types in intermediate internal computations are
> left at compiler default types.  This allows the use of narrower types for
> operational climate simulations (when quicker model execution time is
> necessary) and use wider types for more precise calculations in offline runs,
> without extensive use of C preprocessor that is not a standard Fortran feature.

And, here is the problem with these options.  Users think it
is a great idea to try to promote types without understanding
what the options, so they then just naively use those options
and complain when something goes wrong.

If you use these options with any one file in a project, you must
use them with all files.

> It is puzzling that some of gfortran developers often are advocating
> the use of options like -freal-4-real-8 or -freal-8-real-4 instead.
> These options are as useful as -finteger-4-integer-8 for anything
> but simple single source programs.

These options are preferred (at least by me) because they 
promote all real(4) to real(8) (or real(8) to real(4)) 
regardless of declarations in the code.  There is no ambiguity.
There is no breaking the storage association rules of Fortran;
where the -fdefault-* break storage association.

But, again, if you compile one file with one of these option,
then likely you must compile all files with these options.

>  Consider the following with -O0 -finteger-4-integer-8
> -fdump-tree-original -c:
> 
> program foo
> integer :: t
> call bar(t)
> end program
> 
> subroutine bar(n) ! C callable
> use iso_c_binding,only: c_int
> implicit none
> character(len=4) :: mode = 'test'
> integer(kind=c_int) :: n
> n = -floor(6.)
> call c_func(n, mode)
> end subroutine
> 
> might as well promote integer types in main() too.  It is nearly
> impossible to use -freal-* -finteger-* options when code needs to
> link with libraries like BLAS/LAPACK or optimized variants like
> OpenBLAS, especially when these options prevents *any* use of the
> given type kind and even break fundamental feature like ISO_C_BINDING
> without giving some indication that frontend is doing this. 

It is assumed that the user reads the documentation that comes
with his compiler.  Quoting from gfortran.info


-freal-* family of options

   ...  These options should be used with care and may not be suitable
   for your codes.  Areas of possible concern include calls to external
   procedures, alignment in 'EQUIVALENCE' and/or 'COMMON', generic
   interfaces, BOZ literal constant conversion, and I/O and calls to
   intrinsic procedures when passing a value to the 'kind=' dummy
   argument.  Inspection of the intermediate representation of the
   translated Fortran code, produced by '-fdump-fortran-original' or
   '-fdump-tree-original', is suggested.