On Wed, Nov 14, 2007 at 09:20:40AM -0500, Andy Dougherty wrote: > On Tue, 13 Nov 2007, Nicholas Clark via RT wrote: > > On Mon, Nov 12, 2007 at 12:33:41PM -0800, Andy Dougherty wrote: > > > It may well be there's an issue with gcc's optimizer, since the problem > > > goes away without optimization, but I think it's also fair to say that > > > the definition of FLOAT_IS_ZERO in include/parrot/misc.h is > > > perhaps not optimal here. I'd prefer the simpler definition: > > > > > > #define FLOAT_IS_ZER0(f) ((f) == 0.0) > > > > > > but I didn't get anywhere last time I proposed that. I don't know > > > what else to do. > > > > I suggested > > > > f >= 0.0 && f <= 0.0 > > > > which I believe is identical, even in the face of NaNs, but should also shut > > up the whining, er, warning, about comparison.
Yes, as long as whatever expressions we use for "f" don't have any side effects (but you both already know this :-). > You're probably right. However, given that gcc currently throws over a > thousand warnings it's hard to get worried about about another one or two. IIRC, part of the reason we went to some effort to shut up the floating point comparison warnings from gcc was because there were significantly more than one or two of them. :-) But like Andy I've always been strongly in favor of the ((f) == 0.0) approach and simply turning off the float_equals warnings in gcc. > > Because I would be so bold as to say that the constant zero would be > > exempted from any useful warning about floating point equality check. > > Yes, it's amazing how gcc seems to have hundreds of flags that are almost, > but not quite, entirely unlike the ones you actually want. Well said. Pm
