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

[wschmidt at linux dot ibm.com]

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.

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.