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 rguent...@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
