[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 #13 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Aug 30, 2021 at 03:23:59PM +0000, rimvydas.jas at gmail dot com wrote:
> 
> > You need to use -fdefault-real-8 -fdefault-double-8 when compiling both
> > files.  How is the 2nd invocation of gfortran to know that your first
> > invocation of gfortran used incompatible options?
> Incompatible how?  As far as executable linking is concerned the final link
> could be performed by plain ld(1) on both foo.o and bar.o (or foo.o libbar.a)
> provided that user links in the libgfortran.so too.  The -fdump-tree-original
> -c outputs on both sources indicate that dump trees are identical (including
> calls to _gfortran_reshape_r8() in libgfortran.so).
> 

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.

And, no, I'm not wasting my time contriving examples to prove
that these options should be avoided.