https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 31 Jul 2019, wschmidt at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 > > Bill Schmidt <wschmidt at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Known to fail| |10.0, 8.3.0, 9.1.0 > > --- Comment #13 from Bill Schmidt <wschmidt at gcc dot gnu.org> --- > It dates back to at least 2018-04-12, when it was reported internally on a > SPEC > test. I'll mark known-to-fail for GCC 8 going forward. Note it can also be a binutils issue, there used to be issues with static library handling and builtins eventually not appearing in the LTO symbol table. Indeed for the fortran example I see 1 t.o 8 334 a12b0c6fed53f76a PREVAILING_DEF_IRONLY square_cube_ 348 a12b0c6fed53f76a PREVAILING_DEF main 363 a12b0c6fed53f76a RESOLVED_DYN _gfortran_st_write_done 372 a12b0c6fed53f76a RESOLVED_DYN _gfortran_transfer_integer_write 381 a12b0c6fed53f76a RESOLVED_DYN _gfortran_transfer_character_write 383 a12b0c6fed53f76a RESOLVED_DYN _gfortran_st_write 391 a12b0c6fed53f76a RESOLVED_DYN _gfortran_set_options 396 a12b0c6fed53f76a RESOLVED_DYN _gfortran_set_args and for a corresponding C testcase 1 t.o 3 198 af89597965b857af PREVAILING_DEF main 211 af89597965b857af PREVAILING_DEF_IRONLY z 213 af89597965b857af PREVAILING_DEF_IRONLY y so no atan2 but an external function foo appears. So the linker probably decides MASS is not needed at all and in the end atan2 comes in via libgfortran linking to libm.
