Re: question about equivalent x87/x64-64 fpu code...

[Andrew Haley <aph at redhat dot com>]

On 16/05/11 11:45, Pawel Sikora wrote:
> On Monday 16 of May 2011 11:15:29 Andrew Haley wrote:
>> On 13/05/11 19:11, PaweÅ Sikora wrote:
>>> Hi,
>>>
>>> i'm using a 3rd-party engine http://glaros.dtc.umn.edu/gkhome/metis/metis/overview
>>> for partitioning some complex data. it worked fine for years until today (may 13)...
>>>
>>> observations:
>>> - the 32-bit metis build produces nice and balanced partitons.
>>> - the 64-bit metis build produces bad and unbalanced partitons.
>>>
>>> the metis' engine uses arrays of integers on the public interface and internally
>>> some float-based and unsafe in terms of precison (x<y and x==y) operations.
>>>
>>> so, i've built/tested following metis variants:
>>>
>>> 1). -m32 -march=pentium4 -O1                         - works fine.
>>> 2). -m32 -march=pentium4 -O1 -mfpmath=sse            - works fine.
>>> 3). -m64 -march=x86-64 -O1                           - bad/unbalanced partitions.
>>> 4). -m64 -march=x86-64 -O1 -mfpmath=387              - bad/unbalanced partitions.
>>>
>>> at this point i've expected wrong results (< 80-bit precision) from variants 2/3
>>> and good results from variants 1/4 but the real world differs.
>>>
>>> next, i've isolated a one place in sources with float x<y stmt and changed it
>>> to (x-y)<0.00001. with such change both native 1/3 variants give nice/equivalent results.
>>>
>>> so, where is the problem? is the variants 1/4 really equivalent?
>>
>> It's going to be very hard for gcc specialists to answer this.  You really
>> need a numerical analyst who is familiar with the code to have a look.
>>
>> This may be a gcc bug, or it may be a bug in the code.  It'd impossible
>> to know without doing more digging into the problem.
> 
> Hi,
> 
> i've naturally reported these numerical problems to the author at first place
> but i'm still impressed that code produced by gcc for x87/x86-64 with explicit
> and equal -mpc32/-mfpmath options gives different results.
> 
> should -mpc32 and equal fpmath model produce equal results (no matter good or bad) ?

Not necessarily.  Whatever libraries your code is calling won't be affected
by the compiler options you use, for example.

> or mabye there's a bug in gcc exposed by explicit -fexcess-precision option?

Maybe.

> shoud i report this as potential gcc bug?

No, because we haven't even established that there is a gcc bug yet.
There's little point in reporting a bug without a test case that shows what
gcc is doing wrong.

In general, floating-point on 64-bit x86 is better behaved than on 32-bit.

Andrew.