https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #6 from Joel Sherrill <joel at gcc dot gnu.org> --- (In reply to jos...@codesourcery.com from comment #5) > On Tue, 22 Nov 2016, ubizjak at gmail dot com wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478 > > > > --- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> --- > > For 7.0, somebody changed i[34567]86-*-rtems* entry in libgcc/config.host to > > use t-softfp-sfdftf. Please test the following patch: > > The change was by design meant to ensure that _Float128 was always > available on x86, so that __float128 can always be aliased to _Float128. > Making _Float128 always available means making libgcc support for TFmode > always available. > > I.e., the bug was enabling unintended soft-fp usage of XFmode at the same > time as enabling usage of TFmode. The TFmode functions should be kept in > libgcc while disabling the conversions between XFmode and TFmode for this > case. Any thoughts on how to fix this? I would love a proper fix. But ... My initial reaction is that soft-float on the x86 is of marginal utility anymore and that removing the soft-float multilib on this target for at least rtems is an acceptable solution. Soft float seems to be the thing that breaks on x86 and I don't know that there is really a CPU that needs it anymore.
