Bug#175809: Strange or incorrect floating point behaviour
On Wed, Jan 08, 2003 at 10:16:35AM +0100, Gerhard Wesp wrote:
> Package: g++-3.2
> Version: 3.2.2 20021212 (Debian prerelease)
>
> Note that this problem most likely is present in other g++ versions, and
> also, in similar forms, in other gcc languages.
>
> It was discussed in comp.lang.c++.moderated, cf.
> news:<atq355$9or$1@esel.cosy.sbg.ac.at> and the followup postings.
> Posters suggested it might be a bug in the implementation of
> -ffloat-store and/or related to floating point expressions evaluated at
> compile-time and at runtime with different precisions.
>
> Mathematically, a >= b implies ka >= kb for k >= 0. While I'm well
> aware that not all properties of the reals carry over to floating point
> arithmetic, I certainly would expect this *particular* implication to
> carry over. However, g++ -O3 thinks otherwise.
> My first guess was that this has something to do with internal usage of
> 80 bit floating point values, but this doesn't go well with observation
> 4).
I don't _think_ this is a bug, but my floating point fu is fairly weak.
> #include <cassert>
>
> #if 1
> template< typename T > inline void bound( T & x , T const& u
> ) {
> #else
> inline void bound( double& x , double const& u
> ) {
> #endif
> assert( 1. <= u ) ; // (1)
> if( x < 1. ) { x = 1. ; } // (2)
> if( x > u ) { x = u ; }
> }
At whatever particular flags work or not, I bet this is complex enough
to cause or not cause the value to be computed at run time. Roughly.
> int main() {
> const double u = 2.1 ;
2.1 can not be represented precisely in IEEE FP, of course.
> double x = 3 ;
>
> bound( x , u ) ;
>
> assert( u >= x ) ;
> assert( 2.5*u >= 2.5*x ) ; // fails!!!
The compiler is certainly allowed to compute 2.5*u at compile time. It
does so using an extremely high precision real library, if I recall
correctly. This could be a bug in that library but it's more likely
that the result is a more accurate answer to one bit or thereabouts.
Use a debugger/disassembler? Tell us what the numbers actually _are_?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: