On 11 June 2012 15:00, Dario Saccavino <kathoum@xxxxxxxxx> wrote: > 2012/6/11 Szabolcs Horvát <szhorvat@xxxxxxxxx> >> >> On 8 June 2012 00:50, Ian Lance Taylor <iant@xxxxxxxxxx> wrote: >> > Szabolcs Horvát <szhorvat@xxxxxxxxx> writes: >> > >> >> I am using the Triangle library >> >> <http://www.cs.cmu.edu/~quake/triangle.html> to generate Delaunay >> >> triangulations of a large number of points. When I compile this >> >> library using the -ftree-ter optimization option only, the library >> >> gives me incorrect results for certain inputs. The -ftree-ter option >> >> is enabled by optimization level -O1 or higher, which also cause the >> >> library to return incorrect results. >> >> >> >> Question: Does this indicate that there is a bug in gcc or is it more >> >> likely that there's a problem in how the library is written? >> >> >> >> Unfortunately I am not familiar with the code of Triangle, I just >> >> compile it and use it. >> >> >> >> I tried this with gcc 4.6.3 on Ubuntu and gcc 4.7.0 on Windows (from >> >> <http://nuwen.net/mingw.html>), both 32-bit. >> > >> > >> > While a bug in GCC is always possible, it is more likely that there's a >> > problem in how the library is written. >> > >> >> Unfortunately I am not in a position to find out if it's a problem >> with Triangle as I don't know in detail how it works. Triangle is >> quite extensively used though, and it's last version is from 2005. I >> wonder why the problem has not come out before. >> >> A strange thing is that I get a different kind of incorrect result if >> I use the -O1 option or if I manually specify all the flags that -O1 >> is supposed to turn on. What could be the reason for this? I got the >> list of flags from here: >> http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Optimize-Options.html#Optimize-Options > > That page says "Not all optimizations are controlled directly by a flag. Only > optimizations that have a flag are listed in this section." > This means specifying -O1 is not equivalent to specifying all the > listed options. > >> >> Similarly, using -O1 -fno-tree-ter does NOT fix the problem. >> Specifying all options that -O1 is supposed to imply according to the >> docs, except -ftree-ter DOES fix the problem. >> >> What is the difference between -O1 and listing all options that it implies? > > The library's README file contains the following text: > > Some processors, including Intel x86 family and possibly Motorola 68xxx > family chips, are IEEE conformant but have extended length internal > floating-point registers that may defeat Triangle's exact arithmetic > routines by failing to cause enough roundoff error! Typically, there is a > way to set these internal registers so that they are rounded off to IEEE > single or double precision format. I believe (but I'm not certain) that > Triangle has the right incantations for x86 chips, if you have gcc running > under Linux (define the LINUX compiler symbol) or Microsoft C (define the > CPU86 compiler symbol). > > Unfortunately, the library has not been updated since 2005 and I think > "the right incantation" may not work with a modern version of GCC. > > I suggest trying one of the following: > - define LINUX or CPU86 > - use the option -fexcess-precision=standard > - if your program is not going to run on old hardware, use the > options -mfpmath=sse -msse2 > Thank you Dario, defining CPU86, and making sure that all other necessary defines are present have solved the problem.
