On Thu, 5 Jan 2017, Matthew Fortune wrote: > > > AFAIR we deliberately decided not to define a 2008-NaN soft-float > > > ABI, and chose to require all soft-float binaries to use the legacy > > encoding. > > > > Soft-float and 2008-NaN are naturally completely orthogonal and the > > combination works fine (of course, it doesn't need any special kernel or > > hardware support). There's no need to disallow the combination.
True, however unlike with hard-float we are not constrained by hardware here and IMO the advantage of using 2008-NaN semantics (i.e. payload preservation) does not outweigh the drawback of having two incompatible ABIs and the issue of interlinking between them -- a solution for which which, as it has been shown, causes enough controversy to still have not been agreed upon. Why not avoid it altogether then, as originally chosen, and stick to legacy NaN for all soft-float? > > In any case, the soft-fp change is relevant in the hard-float case as > > well, to make software TFmode behave consistently with hardware SFmode > > and DFmode regarding NaN payload preservation. Is mixing TFmode, DFmode and SFmode operations with the two latters handled in hardware and the former deferred to soft-fp a supported configuration? Do we have any MIPS ABI which provides for using all these data types? AFAIK all MIPS/Linux ABIs use DFmode for `long double' and IRIX support (which did have a TFmode data type, though used an unusual format and didn't support 2008 NaN anyway) has been dropped. Any bare metal targets? I dare say none of the MIPS/*BSD targets supports 2008 NaN; no idea offhand about their TFmode support. > It is true to say that users are discouraged from using 2008-NaN with > soft-float for pre-R6 architectures simply to avoid further fragmentation > of software for no real gain. However, for R6 then soft-float is 2008-NaN > otherwise we are stuck with legacy-NaN forever. What's the actual issue you have with legacy NaN, and how does soft-float relate to R6? It's not like hardware, R6 or othwerwise, limits soft-float in any way. > If someone did want to build a system from source with soft-float as > 2008-NaN then I see no reason to stop them but I doubt they would and I > don't expect the --with-nan GCC configure option to be used in conjunction > with --with-float=soft for the same reason. The most likely use of > --with-nan is to build a distribution specifically to target an MSA capable > system like P5600 or perhaps an M5150 with an FPU. The NaN interlinking > work will make these use-cases less important still though I think. You can have GCC configured with `--with-nan=2008' and equipped with a soft-float multilib. IMHO you ought to be able to just use `-msoft-float' then to select the soft-float multilib and have it implicitly use the legacy NaN encoding rather than having to pass `-msoft-float -mnan=legacy' to get the intended semantics. There shouldn't be a need for NaN interlinking for soft-float objects, that's just unnecessary burden IMO. MSA is irrelevant for soft-float operations, we don't have a soft-float MSA ABI. If we ever define one, then we could well choose the 2008-NaN encoding for compatibility with hard-float code; there's no issue with backwards compatibility here as no legacy-NaN MSA hardware has been ever allowed. Have I missed anything? Maciej