https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120304
--- Comment #5 from Joseph S. Myers <jsm28 at gcc dot gnu.org> --- I agree that it's best not to support legacy __float128 for new architectures; if there are any remaining issues with libgcobol using long double / _Float128, those should be fixed instead. float128-mul-underflow.c is about after-rounding tininess detection. It has a dg-run line restricting it to after-rounding architectures. SPARC is a before-rounding architecture (technically, the architecture supports either after-rounding or before-rounding - the SPARC V9 manual I have to hand says "impl. dep. #55", and also "It is recommended that tininess be detected before rounding."; glibc assumes SPARC is before-rounding and I've never seen any bug reports about that, so maybe after-rounding SPARC implementations don't actually exist). So enabling that test for SPARC does not make sense. Likewise the other tests you mention. sparc*-linux* (with glibc) should be configured with support for 128-bit long double by default. If GCC can find the glibc headers at configure time, this is automatic (with glibc 2.4 and later); otherwise you can use --with-glibc-version to specify the glibc version to be used (mainly relevant for the first-stage compiler to be used to build glibc when bootstrapping a cross toolchain), or --with-long-double-128. When so configured, the relevant functions such as __multc3 should be in libgcc (the underlying soft-fp-based arithmetic is in glibc). That applies to both 32-bit and 64-bit, but maybe you still need -mlong-double-128 in some cases.
