Matthew Fortune <matthew.fort...@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