On 2005-06-16 08:20:20 -0400, Daniel Berlin wrote: > You deny that Bug 21809 is the same bug as Bug 323, which was closed > in 1999?
Yes: Bug 323 as originally reported is really invalid. The C standard doesn't guarantee that y and y2 should exactly be the same value. However bug 21809 (like *some* other bugs duplicated to bug 323) shows a bug in the compiler, since a variable must not have a precision (or range) larger than the one specified by the type. A fix is *possible*: just store the value to memory after a cast or an assignment. Of course, this wouldn't necessarily be efficient, but there could be options to allow the compiler to have a non-comforming behavior. Or the user could get a processor that behaves differently. Dynamical extended precision is allowed by IEEE-754 and a part of the specifications of the x86 processors. So, you can't say that such processors are buggy. On 2005-06-16 10:11:39 -0400, Mark Hahn wrote: > the question then becomes whether GCC is helped or harmed by > its current policy of unpredictable excess precision. BTW, unpredictability, such as in bug 323, is not a bug (according to the C standard). This may be seen as a bad behavior and changing this behavior would be a great improvement, but I don't complain about it here when saying "bug". > the only constructive comment in this thread so far has been that libm > might somehow rely on EP (ie can't use the _FPU_SET_CW workaround). > which code is this? I'd guess it might be related to using series > approximations, and the code could either set CW or accept 64b results. Or the code could be changed: glibc has code that is guaranteed to work in double precision (modulo some bugs), since it is used on processors that have no extended precision. -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / SPACES project at LORIA
