[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 #12 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
(In reply to kargl from comment #11)
> One of these is no like the others. Yes, the behavior is documented,
> and the unlike other result is likely the result that is no desired
> unless the user enjoys chancing numerical precision issues.
$ cat foo.f90 
program foo
   implicit none
   real(kind=4) :: a, b
   real :: x, y
   x = 1.
   y = 3.14159
   a = 1._4
   b = 3.14159_4
   print *, a / b
   print *, x/ y
end program foo
$ gfortran foo.f90 && ./a.out
  0.318310142    
  0.318310142    
$ gfortran foo.f90 -fdefault-real-8 && ./a.out
  0.318310142    
  0.31831015504887655     
$ gfortran foo.f90 -freal-4-real-8 && ./a.out
  0.31831015504887655     
  0.31831015504887655

Looks pretty consistent for me if proper types are used to match the kinds used
in constants like 3.14159_4. The same would apply for plain DOUBLE PRECISION
and 3.14159D numerical constants. Is this the only catch for -fdefault-* family
of options?

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