https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> --- 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?
