[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)

[luoxhu at cn dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287

--- Comment #20 from Xiong Hu XS Luo <luoxhu at cn dot ibm.com> ---

(In reply to rguenther@suse.de from comment #11)
> On Wed, 31 Jul 2019, wschmidt at linux dot ibm.com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> > 
> > --- Comment #10 from wschmidt at linux dot ibm.com ---
> > On 7/31/19 2:25 AM, rguenther at suse dot de wrote:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> > >
> > > --- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
> > > On Wed, 31 Jul 2019, luoxhu at cn dot ibm.com wrote:
> > >
> > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> > >>
> > >> --- Comment #8 from Xiong Hu XS Luo <luoxhu at cn dot ibm.com> ---
> > >> (In reply to Thomas Koenig from comment #6)
> > >>> (In reply to Xiong Hu XS Luo from comment #4)
> > >>>
> > >>>> /tmp/cctrpu2h.ltrans0.ltrans.o: In function `MAIN__':
> > >>>> <artificial>:(.text+0x114): undefined reference to `_gfortran_st_write'
> > >>>> <artificial>:(.text+0x12c): undefined reference to
> > >>>> `_gfortran_transfer_character_write'
> > >>> You're not linkging against libgfortran.
> > >>>
> > >>> Either use gfortran as command for compiling or linking, or
> > >>> add the appropriate libraries (-lgfortran -lquadmath) to
> > >>> the linking step.
> > >> Thanks Thomas and Richard.  Sorry that I am not familiar with fortran.  The
> > >> regression was fixed by Martin's new change.
> > >>
> > >> The c code included math.h actually.
> > >>
> > >> cat atan2bashzowie.c
> > >> #include <stdio.h>
> > >> #include <math.h>
> > >> #include <stdlib.h>
> > >>
> > >> double __attribute__((noinline)) zowie (double x, double y, double z)
> > >> {
> > >>   return atan2 (x * y, z);
> > >> }
> > >>
> > >> double __attribute__((noinline)) rand_finite_double (void)
> > >> {
> > >>   union {
> > >>     double d;
> > >>     unsigned char uc[sizeof(double)];
> > >>   } u;
> > >>   do {
> > >>     for (unsigned i = 0; i < sizeof u.uc; i++) {
> > >>       u.uc[i] = (unsigned char) rand();
> > >>     }
> > >>   } while (!isfinite(u.d));
> > >>   return u.d;
> > >> }
> > >>
> > >> int main ()
> > >> {
> > >>   double a = rand_finite_double ();
> > >>   printf ("%lf\n", zowie (a, 4.5, 2.2));
> > >>   return 0;
> > >> }
> > >> cat build.sh
> > >> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
> > >> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -lmass_simdp8 -lmassv -lmassvp8 -o a.out
> > >> nm a.out | grep atan2
> > >> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
> > >> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto -lmass_simdp8 -lmassv -lmassvp8 -o
> > >> a.out
> > >> nm a.out | grep atan2
> > >> ./build.sh
> > >> 0000000010000700 T atan2
> > >> 0000000010000700 T _atan2
> > >> 00000000100007e0 T atan2
> > >> 00000000100007e0 T _atan2
> > > Err, but [_]atan2 are surely not vector variants.  Also is massv a static
> > > library here?  It looks more like you are not getting the code vectorized
> > > with -flto but without and both variants end up using massv (the -flto
> > > variant using the scalar atan2)?
> > >
> > > That said, you have to do more detailed analysis of what actually
> > > happens and what you _want_ to happen.  The bugreport summary
> > > doesn't really match what you show.
> > >
> > Agree that there's some unnecessary confusion here.  I think the
> > temporary ICE and the build issues obscured the original intent of the bug.
> > 
> > There are two libraries provided with the MASS project.  libmass
> > provides scalar replacements for corresponding libm scalar math
> > functions.  libmassv provides the vectorized versions of those
> > functions.  For this bug we are only concerned about libmass and scalar
> > math functions.
> 
> OK, so -mveclibabi=mass isn't needed to reproduce the issue, nor is
> linking -lmassv or -lmass_smidp8 then I guess.
> 
> > With the C version of the code, we correctly generate symbols atan2 and
> > _atan2 that will be satisfied by libmass.  With the Fortran version of
> > the code and without -flto, we again generate symbols atan2f and _atan2f
> > that will be satisfied by libmass.  When we add -flto to the Fortran
> > version of the code, we instead generate symbols for atan2f@@GLIBC_2.17,
> > disallowing libmass from satisfying them.
> > 
> > We see different behavior in the "visibility" LTO pass between the C and
> > Fortran versions, which seems to be a clue.
> 
> I see (on x86) atan2f being used for the fortran testcase since
> you are calling atan2 with real() arguments.  If you do not use
> -fdefault-real-8 you are then comparing apples and oranges.
> 
> Maybe MASS doesn't have any float variants?

update the fortran case to use real*8 to call atan2 instead of atan2f,
-mveclibabi=mass and -lmassv are unnecessary to reproduce it:
luoxhu@genoa lto $ cat hellofortran.f90
recursive subroutine square_cube(i,isquare,icube)
  REAL*8 j
  REAL*8, DIMENSION(0:1)            :: vector
  integer, intent(in)  :: i             ! input
  integer, intent(out) :: isquare,icube ! output
  !square = i**2
  j = i + 1
  isquare = atan2 ((j), (j+2))
  !do k=0,1
  !vector(k) = atan2 (j, j+k)
  !enddo
  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 lto $ cat build_fortran.sh
echo "mass without  lto"
~/local/gcc_t/bin/gfortran -O3 -mcpu=power9 hellofortran.f90
-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
-L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto
nm a.out |grep atan2

./build_fortran.sh
mass without  lto
0000000010000a40 T atan2
0000000010000a40 T _atan2
mass link with lto
0000000010000730 t 000001f6.plt_call.atan2@@GLIBC_2.17
                 U atan2@@GLIBC_2.17