This is the mail archive of the
mailing list for the GCC project.
RE: [RFC, MIPS] Relax NaN rules
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: Richard Sandiford <rdsandiford at googlemail dot com>, Joseph Myers <joseph 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: Mon, 24 Mar 2014 23:26:50 +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> <87bnwy634z dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1403221217120 dot 23119 at tp dot orcam dot me dot uk> <6D39441BF12EF246A7ABCE6654B023534C982C at LEMAIL01 dot le dot imgtec dot org> <87txap40o2 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534CB2C4 at LEMAIL01 dot le dot imgtec dot org>
On Mon, 24 Mar 2014, Matthew Fortune wrote:
> Yes this is a lot simpler than the 3rd mode but disabling the NAN2008 ELF
> Flag checks is even more honest as that is what would happen at the
> kernel-userland boundary anyway, so why enforce it elsewhere.
> I know I am pushing hard on this topic but I am significantly concerned
> about the impact a whole new build variant has for MIPS and signalling nan
> encoding is a rather trivial topic to cause it.
> Can anyone pinpoint something 'real' that would currently work but would
> fail if the snan encoding changed and was ignored/intermixed? Even if
> there is some genuine use-case then we can still give those
> users the ability to carefully control nan encoding with the work already
What I'm concerned the most about is the matter is so obscure to people
outside a narrow group of hardware/kernel/toolchain/library experts (that
regrettably does not include distribution packagers) that once that "don't
care" approach is set in the environment it'll be used universally because
it's the path of least resistance that'll cause the least trouble for
And then it'll hit another group who are expert on using IEEE maths for
their scientific, etc. purposes and require correct results including NaN
special cases, but then are not necessarily expertly enough or have no
resources to rebuild their kernel/toolchain/library environment to their
needs, or maybe even understand why exactly it does not work as they want.
Plus the incorrect NaN case may actually show up only very infrequently,
may require lots of effort to track down, and may eventually ruin their
Whereas the compromise I proposed will always produce correct results and
I believe will draw anyone's interested attention immediately to bad FP
performance where the wrong binary is used for what hardware used supports
and performance matters. That with a suitable kernel message, e.g.:
<process foo>: Unsupported FP mode requested, switching to software FP
emulation, please recompile with `-mnan=2008' for full performance.
or suchlike I believe will do and point people in the right direction (and
likewise for `-mnan=legacy').
The added benefit will be if a popular piece of software is going to
suffer from that, then people will complain to their distribution supplier
giving the vendor a chance to fix the problem up and supply the binary and
any dependent libraries compiled in the desired NaN mode. Pretty much
like some libraries/executables already supplied by distribution vendors
optimised for particular processor families or features, e.g. in the x86
world (the `cmov' feature/instruction subset comes to my mind).
Any real cons to doing this? Besides having to invest some effort (but
not really that much) into the kernel to implement this switching and
reporting mechanism -- but in real world there's no free lunch and I think
this investment will be worth it.