https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
Bug ID: 91287
Summary: LTO disables linking with scalar MASS library (Fortran
only)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
The MASS (Mathematical Acceleration Subsystem) libraries provide alternatives
to math functions in libm. We've discovered that when compiling a Fortran
program with -flto, the program is linked with libm rather than with the MASS
functions, leading to a degradation in performance versus not using -flto.
luoxhu@genoa test_mass $ cat hellofortran.f90
recursive subroutine square_cube(i,isquare,icube)
integer, intent(in) :: i ! input
integer, intent(out) :: isquare,icube ! output
!square = i**2
isquare = atan2 (real(i), real(2))
icube = i**3
if(i == 8) return
call square_cube(i+1,isq,icub)
end subroutine square_cube
program xx
implicit none
integer :: i,isq,icub
i = 1
call square_cube(i,isq,icub)
print*,"i,i^2,i^3=",i,isq,icub
end program xx
luoxhu@genoa test_mass $ cat build_fortran.sh
echo "mass without lto"
~/local/gcc_t/bin/gfortran -O3 -mcpu=power9 hellofortran.f90 -mveclibabi=mass
-L/opt/mass/8.1.3/Linux_LE/lib/ -lmass
nm a.out |grep atan2
echo "mass link with lto"
~/local/gcc_t/bin/gfortran -O3 -mcpu=power9 hellofortran.f90 -mveclibabi=mass
-L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto
nm a.out |grep atan2
luoxhu@genoa test_mass $ ./build_fortran.sh
mass without lto
0000000010000a40 T atan2f
0000000010000a40 T _atan2f
mass link with lto
00000000100006f0 t 000001f8.plt_call.atan2f@@GLIBC_2.17
U atan2f@@GLIBC_2.17
The issue appears to occur during the "visibility" pass:
no-lto: (always __builtin_atan2f)
hellofortran.f90.013t.ompexp: _3 = __builtin_atan2f (_2, 2.0e+0);
hellofortran.f90.018t.fixup_cfg1: _3 = __builtin_atan2f (_2, 2.0e+0);
lto: (__builtin_atan2f -> atan2f )
hellofortran.f90.013t.ompexp: _3 = __builtin_atan2f (_2, 2.0e+0);
hellofortran.f90.016i.visibility:atan2/3 (atan2) @0x3fffb53e0708
hellofortran.f90.018t.fixup_cfg1: _3 = atan2f (_2, 2.0e+0);
We've observed that the problem does not occur with a similar C/C++ test case.
It's not clear to me whether this is an LTO problem or a Fortran front end
problem.
Thanks to Luo Xiong Hu for the test case and initial investigation.
