When compiling the popular GPC polygon clipping library (http://www.cs.man.ac.uk/~toby/alan/software/) with -O2 or -O3 and then processing a special polygon, it fails with a sigsegv on linux. The program works fine without optimization and with -O. I get the same results with compilers 4.3.2 and 4.3.3, but not with 4.0.2 (at -O3). I've run valgrind on the code and it comes back clean and even works!! I've attached a the preprocessed source (which is large) from the gcc-4.4. This is how it's compile and run: gcc -O2 -o clip main.i gzip -dc polygon.gz | ./clip I've attached also the full source code. I'll try to contact the author as well, perhaps there's a problem with the code when using optimization.
Created attachment 17268 [details] Preprocessed source Compile like this: gcc -O2 main.i -o clip
Created attachment 17269 [details] The data file that causes the core dump run like this: gzip -dc polygon.gz | ./clip
Created attachment 17270 [details] Full source code Full source code, including main.i and gpc code and the polygon that causes the core dump.
I just found out that it compiles at -O2 if I also specify -ffloat-store. So, I'm thinking it might be related to that old bug (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323), which would not entirely be a surprise. It's always an issue for any non-trivial piece of math code.
From the comments I suggest the code does floating point equality compares, which is a dangerous thing to do if you are not knowing what you do. A fix is to instead of x == y use fabs(x - y) <= epsilon.
As mentioned -ffloat-store works so marking this as a dup of bug 323. 32bit x86 is less important these days too. *** This bug has been marked as a duplicate of bug 323 ***