[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478

--- Comment #9 from Joel Sherrill <joel at gcc dot gnu.org> ---
(In reply to joseph@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 joseph@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? :)