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.
