[RFC, MIPS] Relax NaN rules
Richard Sandiford
rdsandiford@googlemail.com
Sat Mar 22 08:36:00 GMT 2014
Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> Thanks Joseph. I guess I'm not really pushing to have don't-care
> supported as it would take a lot of effort to determine when code does
> and does not care, you rightly point out more cases to deal with
> too. I'm not sure if the benefit would then be worth it or not as there
> would still be modules which do and do not care about old and new NaNs
> so it doesn't really relieve any pressure on toolchains or linux
> distributions. The second part of the proposal is more
> interesting/useful as it is saying I don't care about the impact of
> getting NaN encoding wrong and a tools vendor/linux distribution then
> gets to make that choice. Any comments on that aspect?
Maybe it's just me, but I don't understand your use case for (2).
If 99% of users don't care about the different NaN encodings then
why would they use a different -mnan setting from the default?
Are you worried about potential future processors that only support
2008 NaNs? If so, then (a) you give good reasons why that seems like a
misfeature and (b) I think we should instead tackle it by continuing
to allow both -mnan settings for all processors. I.e. we simply wouldn't
add any logic to check "is this processor/architecture compatible with this
encoding?".
Thanks,
Richard
More information about the Gcc
mailing list