4.3.0 strange problem with computation and optimization

4.3.0 strange problem with computation and optimization

[Lasse Kliemann]

[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]

Greetings,

I have a C++ program that does some linear programming optimization. Out of 
this linear programming, I get a vector of doubles `x' and a double `opt' 
that should be the sum of the entries in `x' (`x' is the solution vector and 
`opt' is the optimal value). As a consistency chek, I compute the sum of the 
elements of `x' and then compute the difference to `opt'. It should be close 
to zero. Here is a snippet from the code:

   double sum = 0;
   const double *x = model->getColSolution();
   for (unsigned int j=0; j<m; ++j) sum += x[j];
   double d=opt-sum;
   cout << "difference: " << d << endl;

If I compile that with g++ version 4.3.0 and -O0, -O1, or -Os, everything 
looks OK; in rare cases the difference is zero, and in most cases it is a 
very small number.  Now, if I compile that with -O2 or -O3, the difference is 
*always* printed to be zero, which I presume is wrong.

Now for the weird part. Consider the following code:

   double sum = 0;
   const double *x = model->getColSolution();
   for (unsigned int j=0; j<m; ++j) sum += x[j];
   double d=opt-sum;
   cout << "difference: " << d << endl;
   cout << "difference: " << d << endl;

That is the above with the last line repeated. This works as expected with 
any optimization, i.e., the same (in most cases: non-zero) number is printed 
twice.

There are other strange ways to get this fixed, for example insert a 
statement like

   cout << endl;

between the computation of the sum and the output of `d'. 

I tried to construct a minimal example by writing `x' and `opt' to a file and 
reading it in by a small program which only does the summing up, takes the 
difference and prints it out. Unfortunately, the phenomenon does not show up 
there. Now, I can provide the program where the problem occurred, it's no 
more than 70 lines, but it must be linked against the CLP library (from the 
coin-or.org project).

Hopefully, someone can give me a hint how to track this down further. The 
profile is quite sharp, I think: -O0, -O1, -O2 work, but -O2 and -O3 don't. 
Operating system is Linux 2.6.x on a Intel Xeon E5310.

Thank you!
Lasse

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: 4.3.0 strange problem with computation and optimization

[Andrew Haley]

Lasse Kliemann wrote:
> Greetings,
> 
> I have a C++ program that does some linear programming optimization. Out of 
> this linear programming, I get a vector of doubles `x' and a double `opt' 
> that should be the sum of the entries in `x' (`x' is the solution vector and 
> `opt' is the optimal value). As a consistency chek, I compute the sum of the 
> elements of `x' and then compute the difference to `opt'. It should be close 
> to zero. Here is a snippet from the code:
> 
>    double sum = 0;
>    const double *x = model->getColSolution();
>    for (unsigned int j=0; j<m; ++j) sum += x[j];
>    double d=opt-sum;
>    cout << "difference: " << d << endl;
> 
> If I compile that with g++ version 4.3.0 and -O0, -O1, or -Os, everything 
> looks OK; in rare cases the difference is zero, and in most cases it is a 
> very small number.  Now, if I compile that with -O2 or -O3, the difference is 
> *always* printed to be zero, which I presume is wrong.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323\

Re: 4.3.0 strange problem with computation and optimization

[Andrew Haley]

Andrew Haley wrote:
> Lasse Kliemann wrote:
>> Greetings,
>>
>> I have a C++ program that does some linear programming optimization. Out of 
>> this linear programming, I get a vector of doubles `x' and a double `opt' 
>> that should be the sum of the entries in `x' (`x' is the solution vector and 
>> `opt' is the optimal value). As a consistency chek, I compute the sum of the 
>> elements of `x' and then compute the difference to `opt'. It should be close 
>> to zero. Here is a snippet from the code:
>>
>>    double sum = 0;
>>    const double *x = model->getColSolution();
>>    for (unsigned int j=0; j<m; ++j) sum += x[j];
>>    double d=opt-sum;
>>    cout << "difference: " << d << endl;
>>
>> If I compile that with g++ version 4.3.0 and -O0, -O1, or -Os, everything 
>> looks OK; in rare cases the difference is zero, and in most cases it is a 
>> very small number.  Now, if I compile that with -O2 or -O3, the difference is 
>> *always* printed to be zero, which I presume is wrong.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323\

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Re: 4.3.0 strange problem with computation and optimization

[Tom Browder]

On Wed, Mar 12, 2008 at 12:34 PM, Andrew Haley <aph@redhat.com> wrote:
...
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Did all lose interest?  Or is there a plan to do some kind of fix?

-Tom

Re: 4.3.0 strange problem with computation and optimization

[Andrew Haley]

Tom Browder wrote:
> On Wed, Mar 12, 2008 at 12:34 PM, Andrew Haley <aph@redhat.com> wrote:
> ...
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
> 
> Did all lose interest?  Or is there a plan to do some kind of fix?

See Comment #70.

In any case, this bug (if indeed it is one) is not present on 64-bit
systems, so it's becoming irrelevant.

Andrew.

Re: 4.3.0 strange problem with computation and optimization

[Dario Saccavino]

> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
>
>
> Did all lose interest?  Or is there a plan to do some kind of fix?
>

I haven't found any comment on the effect of sse/sse2 on this "bug".

Anybody knows if using -msse2 -mfpmath=sse can help obtain a better
conformant assembly? The sse regs should have the correct precision
(32 for float, 64 for double), so maybe part of the undesired
behaviour can be avoided.

    Dario

Re: 4.3.0 strange problem with computation and optimization

[Ian Lance Taylor]

"Dario Saccavino" <kathoum@gmail.com> writes:

> Anybody knows if using -msse2 -mfpmath=sse can help obtain a better
> conformant assembly? The sse regs should have the correct precision
> (32 for float, 64 for double), so maybe part of the undesired
> behaviour can be avoided.

Yes, using those options makes your floating point operations
generally immune to gcc's register allocation decisions.

That is the default in 64-bit mode.

Ian

Re: 4.3.0 strange problem with computation and optimization

[Lasse Kliemann]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

* Message by -Dario Saccavino- from Thu 2008-03-13:
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
> >
> >
> > Did all lose interest?  Or is there a plan to do some kind of fix?
> >
> 
> I haven't found any comment on the effect of sse/sse2 on this "bug".
> 
> Anybody knows if using -msse2 -mfpmath=sse can help obtain a better
> conformant assembly? The sse regs should have the correct precision
> (32 for float, 64 for double), so maybe part of the undesired
> behaviour can be avoided.

All I can tell you is that after a study of several comments, I chose to use 
that. So far, I have no complaints about it. In fact, I am using -mssse3, 
which seems to be the "highest" such extension on the Xeon 5310, according to 
/proc/cpuid. I could not measure any performance gain compared to -msse2, 
however.

Next step will be to install a 64 bit system.

Lasse

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: 4.3.0 strange problem with computation and optimization

[Tim Prince]

Lasse Kliemann wrote:
> Greetings,
> 
> I have a C++ program that does some linear programming optimization. Out of 
> this linear programming, I get a vector of doubles `x' and a double `opt' 
> that should be the sum of the entries in `x' (`x' is the solution vector and 
> `opt' is the optimal value). As a consistency chek, I compute the sum of the 
> elements of `x' and then compute the difference to `opt'. It should be close 
> to zero. Here is a snippet from the code:
> 
>    double sum = 0;
>    const double *x = model->getColSolution();
>    for (unsigned int j=0; j<m; ++j) sum += x[j];
>    double d=opt-sum;
>    cout << "difference: " << d << endl;
> 
> If I compile that with g++ version 4.3.0 and -O0, -O1, or -Os, everything 
> looks OK; in rare cases the difference is zero, and in most cases it is a 
> very small number.  Now, if I compile that with -O2 or -O3, the difference is 
> *always* printed to be zero, which I presume is wrong.
> 
> Now for the weird part. Consider the following code:
> 
>    double sum = 0;
>    const double *x = model->getColSolution();
>    for (unsigned int j=0; j<m; ++j) sum += x[j];
>    double d=opt-sum;
>    cout << "difference: " << d << endl;
>    cout << "difference: " << d << endl;
> 
> That is the above with the last line repeated. This works as expected with 
> any optimization, i.e., the same (in most cases: non-zero) number is printed 
> twice.
> 
> There are other strange ways to get this fixed, for example insert a 
> statement like
> 
>    cout << endl;
> 
> between the computation of the sum and the output of `d'. 
> 
> I tried to construct a minimal example by writing `x' and `opt' to a file and 
> reading it in by a small program which only does the summing up, takes the 
> difference and prints it out. Unfortunately, the phenomenon does not show up 
> there. Now, I can provide the program where the problem occurred, it's no 
> more than 70 lines, but it must be linked against the CLP library (from the 
> coin-or.org project).
> 
> Hopefully, someone can give me a hint how to track this down further. The 
> profile is quite sharp, I think: -O0, -O1, -O2 work, but -O2 and -O3 don't. 
> Operating system is Linux 2.6.x on a Intel Xeon E5310.

I don't recall if this is a repeat of a previous post.  As you talk about
differences with optimization level, I assume you have not specified
-mfpmath=sse, and your sum variable is implicitly promoted to long double
in some cases.  This issue has been around ever since the 68881 and 80287
were invented, so there are plenty of places to read about it.  I believe
others have informed you that gcc is not about to disable support for old
CPUs, or even optimization for not so old ones, simply because Microsoft
has hidden the issue from you.