https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956
--- Comment #16 from gaiusmod2 at gmail dot com --- "rguenth at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956 > > --- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> --- > (In reply to Gaius Mulley from comment #14) >> Ah apologies, is it best that I revert: >> >> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git; >> h=81d5ca0b9b8431f1bd7a5ec8a2c94f04bb0cf032 >> >> happy to do this in the morning. > > I think it might be better to define > M2C_LONGREAL_FLOAT128/M2C_LONGREAL_PPC64LE > (whatever they exactly indicate) in terms of the existing > > --with-long-double-128 > --with-long-double-format > > aka the TARGET_DEFAULT_LONG_DOUBLE_128 that's put into the config plus > with_long_double_format (I think that causes TARGET_IEEEQUAD_DEFAULT > to be defined to 1/0, but only for ppc, via config.gcc and > tm_defines). yes thanks for the hints this sounds good. I'll pursue this line for a fix. > I can't say whether it's better to revert or disable/fix as I can't say > how this for example affects the M2 ABI (like if there was any 'long double' > before this change and what effective type this used). Prior to the patch it used the default C long double type but many of the intrinsic functions were broken. Currently with the patch gcc120 has no regression test failures and gcc135 (yesterday with manual configure intervention) was at 96 failures in the m2 testsuite. I suspect configure confusion and hence using TARGET_DEFAULT_LONG_DOUBLE_128 and TARGET_IEEEQUAD_DEFAULT should resolve it.
