Re: Remove LIBGCC2_HAS_?F_MODE target macros

[<Paul_Koning at Dell dot com>]

On Sep 11, 2014, at 9:22 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:

> This patch removes the LIBGCC2_HAS_{SF,DF,XF,TF}_MODE target macros,
> replacing them by predefines with -fbuilding-libgcc, together with a
> target hook that can influence those predefines when needed.
> 
> The new default is that a floating-point mode is supported in libgcc
> if (a) it passes the scalar_mode_supported_p hook (otherwise it's not
> plausible for it to be supported in libgcc) and (b) it's one of those
> four modes (since those are the modes for which libgcc hardcodes the
> possibility of support).  The target hook can override the default
> choice (in either direction) for modes that pass
> scalar_mode_supported_p (although overriding in the direction of
> returning true when the default would return false only makes sense if
> all relevant functions are specially defined in libgcc for that
> particular target).
> 
> The previous default settings depended on various settings such as
> LIBGCC2_LONG_DOUBLE_TYPE_SIZE, as well as targets defining the above
> target macros if the default wasn't correct.
> 
> The default scalar_mode_supported_p only declares a floating-point
> mode to be supported if it matches one of float / double / long
> double.  This means that in most cases where a mode is only supported
> conditionally in libgcc (TFmode only supported if it's the mode of
> long double, most commonly), the default gets things right.  Overrides
> were needed in the following cases:
> 
> * 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?

	paul