Incorrect results from numerical library when using -ftree-ter

Incorrect results from numerical library when using -ftree-ter

[Szabolcs Horvát]

Hello,

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.

Szabolcs

Re: Incorrect results from numerical library when using -ftree-ter

[Ian Lance Taylor]

Szabolcs Horvát <szhorvat@gmail.com> 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.

Ian

Re: Incorrect results from numerical library when using -ftree-ter

[Szabolcs Horvát]

On 8 June 2012 00:50, Ian Lance Taylor <iant@google.com> wrote:
> Szabolcs Horvát <szhorvat@gmail.com> 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

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?

Re: Incorrect results from numerical library when using -ftree-ter

[Dario Saccavino]

2012/6/11 Szabolcs Horvát <szhorvat@gmail.com>
>
> On 8 June 2012 00:50, Ian Lance Taylor <iant@google.com> wrote:
> > Szabolcs Horvát <szhorvat@gmail.com> 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

    Dario

Re: Incorrect results from numerical library when using -ftree-ter

[Szabolcs Horvát]

On 11 June 2012 15:00, Dario Saccavino <kathoum@gmail.com> wrote:
> 2012/6/11 Szabolcs Horvát <szhorvat@gmail.com>
>>
>> On 8 June 2012 00:50, Ian Lance Taylor <iant@google.com> wrote:
>> > Szabolcs Horvát <szhorvat@gmail.com> 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.