> > So, for this case, there is typically no good workaround. Maybe part of the problem can be reduced by using '#pragma STDC FENV_ACCESS'? Haven't tried that. And it won't help fixing the issue of the i386 ABI requiring 'float' and 'double' values in 387 registers.
Paul Eggert wrote: > Yes, my impression is that signaling NaNs have never been that reliable. In my tests so far, they seem to be reliable except on x86 and sh4 CPUs. (For sh4, because of a gcc bug.) > W. Kahan later wrote > that signaling NaNs "exist mainly for political reasons and are rarely > used"[2], and he was pretty much on target. Yes, the fact that it takes decades for the compilers to get better at not doing optimizations that kill SNaNs, and the fact that it has major problems in i386 certainly did not help the adoption. > PS. At a dinner with Kahan in 1980 I got into an argument with him about > merits and drawbacks of the IEEE floating point design. I also had my qualms with it: In a soft-float implementation, the handling of NaNs, infinities, minus zero, and subnormals consumes too much code and too many code cycles. And that was even without the 5 "exception" flags... The only way to make it efficient was to bake it in hardware. But it's good that there was a normalization. Without Kahan, we would still have to handle VAX D-floats, F-floats, G-floats, and what else. Bruno
