This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC, MIPS] Relax NaN rules

Matthew Fortune <> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]