https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #12 from Bill Schmidt <wschmidt at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #11) > On Wed, 31 Jul 2019, wschmidt at linux dot ibm.com wrote: > > OK, so -mveclibabi=mass isn't needed to reproduce the issue, nor is > linking -lmassv or -lmass_smidp8 then I guess. That's correct. That was just our standard set of flags for linking with MASS/MASSV. It was confusing. > > > 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? No, this used to work. It looks like this started happening a couple of releases ago. We need to drill down on that.
