https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #9 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.(In reply to Uroš Bizjak from comment #8) > (In reply to jos...@codesourcery.com from comment #7) > > On Tue, 17 Jan 2017, joel at gcc dot gnu.org wrote: > > > > > > 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. > > > > Well, you need to distinguish a genuine sfdftf case from sfdfxftf which it > > appears this t- file really is. Distinguish by some configure test that > > determines whether there is XFmode support for the multilib being > > compiled, I suppose (look at the other tmake_file settings in config.host > > based on variables set by configure tests). > > Maybe just add a new t-file without any XFmode and add it to > i[34567]86-*-rtems*) instead of t-sfdftf. I could pursue this but is soft-float on the x86 target really worth the investment of any effort? AFAIK we would be looking at a very old CPU at this point. I only see soft-float listed as a multilib in t-rtems. Is there any reason to keep it? :)
