-ffloat-store requires rewriting existing code. Some libraries, like LAPACK and SLATEC, require fp arithmetic at IEEE single/double precision, and are heavily affected by the way floating point code is handled by gcc. In my opinion, these violates pragmatics of the single/double types: 1. floating point conversions do not round the values, e.g. a double converted to single remains long double in the register (the conversion is performed only on assignment to a variable when -ffloat-store is in effect) 2. comparisons are performed on the long double values from the registers, not on the values rounded to the appropriate precision, hence comparison does not result in equality, even if it takes place at the appropriate precision level (single/double), e.g. 0.1 + 0.4 > 0.5 in floats, altough it's not
Not a bug, read the references in bug 323. *** This bug has been marked as a duplicate of 323 ***
Subject: Re: issues related to floating point precision On Sun, 6 Jun 2004, pinskia at gcc dot gnu dot org wrote: > Not a bug, read the references in bug 323. You mean "known bug", not "not a bug". Excess precision is allowed by C99, and you can even define FLT_EVAL_METHOD to -1 to say that it's indeterminate when there's excess precision (which at present it is, given that spills reduce excess precision unpredictably), but we define FLT_EVAL_METHOD to 2 on x86 (saying that expressions are predictably evaluated as long double), and even with -ffloat-store we don't follow the standard rules that conversions to the same or narrower type (by assignment, cast and (probably) function call and return) get rid of excess precision (but note that conversions of float to double don't get rid of excess precision even if the float is being stored with the precision of long double). That we don't get rid of excess precision on casts is clearly a bug, as is the bad definition of FLT_EVAL_METHOD.
Subject: Re: issues related to floating point precision On Sun, Jun 06, 2004 at 07:35:12PM -0000, jsm at polyomino dot org dot uk wrote: > > ------- Additional Comments From jsm at polyomino dot org dot uk 2004-06-06 19:35 ------- > Subject: Re: issues related to floating point precision > > On Sun, 6 Jun 2004, pinskia at gcc dot gnu dot org wrote: > > > Not a bug, read the references in bug 323. > > You mean "known bug", not "not a bug". Excess precision is allowed by > C99, and you can even define FLT_EVAL_METHOD to -1 to say that it's What about fortran and the comparison issues? It seems that the Intel compiler takes care of them. Consider this example: //assume that float x=0.4, y=0.1; // I mean float values! //then let float z=x+y; //then this is true with -ffloat-store, // bacause z is chopped to 0.5, whereas x+y not: if(x+y > z) printf("not good...\n"); This issue is the reason for a failure with BLAS test. BTW, being within the standards does not mean being useful. Regards, C.S. > indeterminate when there's excess precision (which at present it is, given > that spills reduce excess precision unpredictably), but we define > FLT_EVAL_METHOD to 2 on x86 (saying that expressions are predictably > evaluated as long double), and even with -ffloat-store we don't follow the > standard rules that conversions to the same or narrower type (by > assignment, cast and (probably) function call and return) get rid of > excess precision (but note that conversions of float to double don't get > rid of excess precision even if the float is being stored with the > precision of long double). That we don't get rid of excess precision on > casts is clearly a bug, as is the bad definition of FLT_EVAL_METHOD. > > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15852 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter.