This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Optimize flag breaks code on many versions of gcc (not all)


On 6/18/06, Paolo Carlini <pcarlini@suse.de> wrote:
Zdenek Dvorak wrote:

>...                     I suspect there is something wrong with your
>code (possibly invoking some undefined behavior, using uninitialized
>variable, sensitivity to rounding errors, or something like that).
>
>
A data point apparently in favor of this suspect is that the "problem"
goes away if double is replaced everywhere with long double...

Paolo.

As suspected by everybody, this is a bug in the code.


From your original code:

110 coord[i]=start[i]+maxT[whichPlane]*dir[i]; 111 // **** Uncomment one of these to make the program work. 112 //sleep(0); 113 //cerr << ""; 114 if ((coord[i]<ll[i]) || (coord[i]>ur[i])) { 115 // outside box 116 return false; 117 }

The compiler is allowed to calculate coord[i] at 110 in 80-bit
and use that in the comparison at line 114.
One way to see this impact, without debugging at the assembly level,
is to change the code to:

   110      long double temp;
   111      temp = start[i]+maxT[whichPlane]*dir[i];
   112      // **** Uncomment one of these to make the program work.
   113      //sleep(0);
   114      //cerr << "";
   115      if ((temp<ll[i]) || (temp>ur[i])) {

If you try this code, you'll find that this always fails
and if you inspect temp and ur[i], you'll find that they are very close -
within 1 ULP of double precision.

One bandaid for this problem is to use -ffloat-store
but you'll suffer the performance penalty and it won't really fix
the root cause - which is your code.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]