[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 #17 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Aug 30, 2021 at 07:08:07PM +0000, rimvydas.jas at gmail dot com wrote:
> 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};

gfortran works just fine if one DOES NOT USE DUBIOUS
OPTIONS to try to change the precision of a type to
another precision.

There is Fortran code in libgfortran that is compiled
by gfortran when the compiler is built.  Whether that
code works as intended when someone uses -fdefault-*
or -freal-* family options remains to be seen.

The ISO C Binding module is built on-the-fly, so will 
likely work except it cannot change the properties of
the companion C types.  REAL(c_float) should map to
C's float.  Fortunately, -fdefault-real-8 does not
promote REAL(c_float) (aka REAL(4)) to REAL(8); OTOH
-freal-4-real-8 will do the promotion.

The IEEE ARITHMETIC module is partially built on-the-fly
when compiling code with some information coming from files
in gcc/libgfortran/ieee.  Those files are compiled when
gfortran is builti. I don't know if anyone has extensively
tried these options with IEEE modules.

> 
> > 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.
> 

Of course, these new red herring aren't related to this PR.

COMMON, EQUIVALENCE, BOZ, external subprogram, etc are related
because these are affected by mucking around with storage
assocation and the ABI.