[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 #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Aug 16, 2021 at 09:15:11AM +0000, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
> 
> --- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
> Now I wonder, since libgfortran doesn't change itself, why the fortran
> FE does not properly change _gfortran_pack to resolve to _gfortran_pack_r8?

The answer to your question lies in iresolve.c(gfc_resolve_pack).
A call to _gfortran_pack_r8 is never generated.  See the output
after compiling 

subroutine foo4
  implicit none
  real(4) :: ar(2,3), v(1)
  ar = 0.
  ar(1,1) = 1.
  v = PACK(ar, ar > 0.)
end subroutine

subroutine foo8
  implicit none
  real(8) :: ar(2,3), v(1)
  ar = 0.
  ar(1,1) = 1.
  v = PACK(ar, ar > 0.)
end subroutine

with the "gfortran -c -fdump-tree-original".

Essentially, a combination of in-line generated code and
converting the array of REAL(4) or REAL(8) to a stream of
bytes allows for a single library routine instead of the
combinatoric number of all combinations of argument kind
types (see the packing of the parm.0 and parm.1 structs
in -fdump-tree-original output). 

If someone wants to use -fdefault-* options, then all
code must be compiled with that option.