Re: Remove LIBGCC2_HAS_?F_MODE target macros

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 12 Sep 2014, Paul_Koning@Dell.com wrote:

> > * SFmode would always have been supported in libgcc (the condition was
> >  BITS_PER_UNIT == 8, true for all current targets), but pdp11
> >  defaults to 64-bit float, and in that case SFmode would fail
> >  scalar_mode_supported_p.  I don't know if libgcc actually built for
> >  pdp11 (and the port may well no longer be being used), but this
> >  patch adds a scalar_mode_supported_p hook to it to ensure SFmode is
> >  treated as supported.
> 
> I thought it does build.  I continue to work to keep that port alive.
> 
> The change looks fine.
> 
> The ideal solution, I think, would be to handle the choice of float 
> length that the pdp11 target has via the multilib machinery.  Currently 
> it does not do that.  If multilib were added for that at some point, 
> would that require a change of the code in that hook?

I think the ideal is for the back end to accept a mode in 
scalar_mode_supported_p if it can generate something sensible (either 
inline code or calls to libgcc functions) for arithmetic on that mode, 
rather than ICEs or otherwise invalid code, even if the libgcc functions 
don't actually exist.  (Thus, ix86_scalar_mode_supported_p always 
considers TFmode to be supported, whether or not the libgcc support is 
present.)

On that basis, my hook to treat SFmode as always supported for pdp11 (so 
it can be accessed with __attribute__((mode(SF))), whether or not it's 
also float) seems to be the right thing.

(Various back ends would, if they adopted my ideal, then also need to add 
the libgcc_floating_mode_supported_p hook to indicate the conditional lack 
of libgcc support for certain modes.  E.g. for several back ends, TFmode 
is only supported in libgcc if it's long double, and most of the runtime 
support is expected to be in libc not libgcc, under symbol names from some 
ABI for that architecture.  In those cases, building in the libgcc support 
for e.g. __multc3 in the absence of libc support would be problematic, 
because it would reference undefined libc functions.)

-- 
Joseph S. Myers
joseph@codesourcery.com