They made a related project - http://herbgrind.ucsd.edu/ - a tool that can automatically find floating point issues in real programs. You can also annotate the region you're interested in with herbgrind on/off controls.
Unfortunately - once you know you have a floating point problem, tracking it down and fixing it may be easy. Not realising it, you won't use these tools and the program will do the wrong thing :)
Very true. Floating point bugs are hard to find, because there's often no way to compute a more accurate answer. Herbgrind was our attempt at helping track down a root cause once you knew floating point was the problem---that might be the case if, for example, you changed from double to single precision and suddenly the result was way off. But Herbgrind is pretty high overhead; you'd want some other tool to tell you that floating point was a problem to begin with.
Oh nice, this is new to me. Herbgrind does dynamic analysis, but doesn't this mean it doesn't know which values are to be treated as variables?
Once I hooked Herbie up to the Clang Static Analyzer to pull out expressions from code and suggest alternatives. It wasn't a great fit---CSA doesn't model floating point, and it would consider every sub-expression separately as it explored the program. But I think there's merit to the idea.
That's right, Herbgrind doesn't know which values are variables. It uses antiunification to see which values are always the same (which it assumes are constants) and which differ between invocations (which it assumes are variables).
Unfortunately - once you know you have a floating point problem, tracking it down and fixing it may be easy. Not realising it, you won't use these tools and the program will do the wrong thing :)