On Tue, 18 Mar 2014, Matthew Fortune wrote: > 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.
In general you can't tell whether a module cares. It could have an initializer 0.0 / 0.0, without having any function calls involving floating point (so in principle being independent of hard/soft float, but not of NaN format). Or it could be written with knowledge of the ABI to do things directly with bit patterns (possibly based on a configure test rather than __mips_nan2008). The concept of a don't-care module is meaningful, but while heuristics can reliably tell that a module does care (e.g. GCC generated an encoding of a NaN bit-pattern, whether from __builtin_nan or 0.0 / 0.0) they can't so reliably tell that it doesn't care (although if it doesn't contain NaN bit-patterns, or manipulate representations of floating-point values through taking their addresses or using unions, you can probably be sure enough to mark it as don't-care - note that many cases where there are calls with floating-point arguments and results, but no manipulation of bit-patterns and no NaN constants, would be don't-care by this logic). -- Joseph S. Myers jos...@codesourcery.com
