On Fri, 12 Sep 2014, paul_kon...@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 jos...@codesourcery.com