https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> --- On June 3, 2019 6:54:10 PM GMT+02:00, "tkoenig at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278 > >--- Comment #9 from Thomas Koenig <tkoenig at gcc dot gnu.org> --- >Created attachment 46446 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46446&action=edit >LTO tree dump from simple test case > >So, I tried out a simple program: > >$ cat minloc.f90 >program main > real, dimension(10,10) :: a > integer, dimension(2) :: m1 > call random_number(a) > m1 = minloc(a) > print *,m1 >end program main > >Compiling this with the fat-object libgfortran results in the somewhat >humorous > >$ gfortran -fdump-tree-optimized -O3 -flto -static-libgfortran >minloc.f90 >minloc.f90:5: warning: type of '_gfortran_minloc0_4_r4' does not match >original >declaration [-Wlto-type-mismatch] > 5 | m1 = minloc(a) > | >../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: type >mismatch >in parameter 3 >../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: >'minloc0_4_r4' >was previously declared here >../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: code >may be >misoptimized unless '-fno-strict-aliasing' is used > >which looks like an LTO bug. It tells you the actual argument of the Fortran frontend generated call is not compatible with the C prototype. It Doesn't say which types are involved here and the leading sentence is confusing. >There is a lot of code pulled in for writing to standard output >which could be optimized away. > >The good news: Inlining _gfortran_minloc0_4_r4 appears to work :-)
