[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 #14 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
(In reply to Steve Kargl from comment #13)
> The -fdefault-* options change the storage association rules
> in a way that breaks Fortran.  Places of concern include, but
> are not limited, to COMMON, EQUIVALENCE, maybe the TRANSFER
> intrinsic, BOZ conversion, calling external routines, etc.
Actually the
https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html and
gfortran.1 manpage list this definition for -freal-*-real-* options, while:

-fdefault-real-8
    Set the default real type to an 8 byte wide type. This option also affects
the kind of non-double real constants like 1.0. This option promotes the
default width of DOUBLE PRECISION and double real constants like 1.d0 to 16
bytes if possible. If -fdefault-double-8 is given along with fdefault-real-8,
DOUBLE PRECISION and double real constants are not promoted. Unlike
-freal-4-real-8, fdefault-real-8 does not promote variables with explicit kind
declarations.

> And, no, I'm not wasting my time contriving examples to prove
> that these options should be avoided.
Fair enough, but these Fortran legacy features like COMMON, EQUIVALENCE, BOZ
and calling external user routines without interface have nothing in common
with original PR report or more trivial _gfortran_reshape_r8 example in Comment
#8

I tried to get more information with lto-dump(1) tool, however
lto-dump -dump-body=foo foo.o
lto-dump -dump-body=bar bar.o
outputs do not indicate any tree differences either.  Is there a way to get
more LTO information to understand the issue at hand?