"Maciej W. Rozycki" <ma...@codesourcery.com> writes: > 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 > distributions. > > 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 > work. > > 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.
I think Matthew's point is that some systems (like Android) really aren't going to provide separate system libraries for both encodings. So with the ELF flag scheme as it is today, you won't be able to recompile with a different -mnan flag, because there are no libraries that would be compatible with it. Thanks, Richard
