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. Note, there is no option to silence warnings about numerical constants (not using explicit kinds) when constants can be converted without loss of precision including for powers of 2 in floating types. 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. 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. In many bigger climate packages it is common to use different kinds for IO, computation, coupling etc: ones based on defaults for given architecture/ABI: logical integer real double precision quad precision (when it becomes part of the standard, since hardware is becoming available for scientific computations) ones based on minimal precision required: real, parameter :: jprf = selected_real_kind(6,37) real, parameter :: jprd = selected_real_kind(13,300) integer, parameter :: jpii = selected_int_kind(9) integer, parameter :: jpil = selected_int_kind(13) ones based on Fortran internal storage (a.k.a "works on compilers tested"): real, parameter :: jpr4 = 4 real, parameter :: jpr8 = 8 integer, parameter :: jpi4 = 4 integer, parameter :: jpi8 = 8 ones based on C/Fortran bindings through iso_c_binding integer(kind=c_int) integer(kind=c_long) real(kind=c_float) real(kind=c_double) Users usually do not expect numeric kinds to match between all these groups for all architectures/ABIs, but it is expected that the compiler should convert variable types (including numeric constants) with different kinds or give a diagnostic when it is not possible, otherwise whole use of different explicit kinds is redundant if those internally map to the same kind that can be overridden silently by a single option. If it is indeed just an LTO implementation limitation, then users need to be careful when checking what dynamic or static different climate libraries (possibly using -flto) are being used when linking final executables. Even added diagnostics when the user makes a typo like: integer(kind=selected_real_kind(13,300)) :: i would help a lot. At least some common examples of what to look for in documentation about "gfortran -fdefault-real-8 -fdefault-double-8" limitations (if these options are really that broken) would be very appreciated by the software porters :)
