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

["rimvydas.jas at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #16 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
(In reply to Steve Kargl from comment #15)
> I'm also the person that made these options work
> for some definition of "work", and I have always considered
> these options to be broken because of what you are re-discovering.
> The words of caution for -freal-* and family of options also
> applies to the -fdefault-* options.  I suspect much of work
> done on the intrinsics modules is done independently and
> obliviously to these options.
Statement like this implies that gfortran does *not* properly support variables
using explicit kinds like selected_real_kind(13,300) or real(kind=8) or
real(kind=16) or ISO_C_BINDING ones other than default plain REAL.  From
-ftree-dump-original dumps it is seen that even plain REAL or DOUBLE PRECISION
are assigned REAL(KIND=N) for all types, like
static real(kind=8) b[4] = {[0 ... 3]=1.0e+0};

> COMMON, EQUIVALENCE, and BOZ are not legacy features.
> These are full fledged features of modern Fortran. 
Some people still prefer to use Hollerith constants, implicit types, statement
functions, arithmetic if's, shared do terminations, fixed source form, even
PAUSE and there is nothing wrong with it.  Still, these are not related to this
PR.

> The original problem is simply another manifestation of 
> why these options should be avoided, if not removed from
> gfortran.  In your original example, you have changed the
> ABI between foo.o and bar.o, which now confuses lto.
ABI in this case can not be broken because no data is exchange between foo()
and bar(), nor libgfortran.so.5.0.0 is being recompiled.  Only thing that might
affect the runtime is:
  static integer(kind=4) options.4[7] = {2116, 4095, 0, 1, 1, 0, 31};
  _gfortran_set_options (7, &options.4[0]);
and based on
https://gcc.gnu.org/onlinedocs/gfortran/_005fgfortran_005fset_005foptions.html
these should not influence how runtime library should handle default
integer/real/logical/character types without explicit kind.

Again question is what is getting broken and what is the scope of this?  Is it
limited to LTO compilation only?  Any help to understand the actual problem
would very likely lead to a simple one line fix in the source code.