Hi, I've sent this email to everyone who had opinions about the introduction of nan-2008 for mips according to the mailing list archives...
The NaN linkage rules introduced with -mnan=2008 enforce a strict rule that all code be built with either legacy NaN or 2008 NaN. This impacts both static and dynamic link and is implemented via an ELF flag. Two of the original threads about this are copied below for reference. http://sourceware.org/ml/binutils/2013-07/msg00072.html http://sourceware.org/ml/libc-ports/2013-08/msg00030.html There are two limitations with the current support which make it difficult to use in production environments: 1) There is no way to mark a module as "don't care/not relevant". At a minimum this could be done via inspection of the GNU FP ABI attribute and when its value is 'Any' then NaNs don't matter. Better still would be that modules with floating point only require a certain NaN state if they use functions like __builtin_[s}nan. This would partially reduce the impact of the strict NaN checks. 2) Independent of (1), the strictness associated with NaN handling is a serious problem for linux distributions where there is slow (if any) acceptance of new build variants. New build variants for distributions cost months to put together (just from build time alone) and then the fractured ecosystem this leads to means they are either unused or at best make users confused. It is also true that linux derivatives like Android (and other projects which seek to be architecture agnostic) simply cannot tolerate incompatibilities like the NaN handling rules and will not introduce more than one variant for native code. I believe that 99% of users don't care about the difference between signalling and quiet NaNs and even fewer actually turn on trapping for signalling NaNs. Those who do use, and rely on, behaviour of signalling NaNs very much know that they need this and can afford some extra effort to ensure that they are handled as expected. The following thread is one discussion about how sNaN is a somewhat pointless concept for most users: http://gcc.gnu.org/ml/gcc/2013-11/msg00106.html My proposal is that NaN handling, as implemented, remains but we turn it off by default (or allow it to be turned off by default at build time). By this I mean that GCC will use the default dynamic linker even in the presence of -mnan=2008 and ld will happily link together legacy and 2008 NaN code and ld.so will happily do the same. If a user really cares about NaNs then they need to firstly find someone who will build them a Linux distribution to support them and secondly pull a link time switch '-mstrict-nan' to enable the NaN checks as currently implemented. The same functionality would then be supported by ld.so via an environment variable (or whatever other runtime configuration source there is) to indicate that it must enforce NaN checks as well. Suggestions for option names are welcome. Initial suggestion: --with-nan-check=no, -m[no-]strict-nan, <not sure on env variable for ld.so>. Regards, Matthew
