This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC, MIPS] Relax NaN rules
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, "macro\ at codesourcery dot com" <macro at codesourcery dot com>, "dalias\ at aerifal dot cx" <dalias at aerifal dot cx>, "Andrew Pinski \(pinskia\ at gmail dot com\)" <pinskia at gmail dot com>, "gcc\ at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>, "Moore\, Catherine \(Catherine_Moore\ at mentor dot com\)" <Catherine_Moore at mentor dot com>
- Date: Sat, 22 Mar 2014 08:36:44 +0000
- Subject: Re: [RFC, MIPS] Relax NaN rules
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B023534C5168 at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1403181418140 dot 29154 at digraph dot polyomino dot org dot uk> <6D39441BF12EF246A7ABCE6654B023534C596B at LEMAIL01 dot le dot imgtec dot org>
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