G++ 4.3.4 vs.G++ 4.5.2???

G++ 4.3.4 vs.G++ 4.5.2???

[Jan Chludzinski]

Just finished compiling some numerical code (developed using the
Borland C++ compiler) using G++ 4.3.4 (that came with Cygwin 1.7). The
answers are different from what I get using the Borland compiler
(circa 2002).  I have known correct answers from some NASA code and
compare against those.

I've transitioned of late to Code::Blocks using the latest MinGW.
MinGW comes with G++ 4.5.2.  I compiled using this compiler and it
once again works (I get the same answers as the NASA code).

Are there known problems with G++ 4.3.4?

BTW, the original code was infinite looping until I replaced the old style:

for (i=0; i<WHATEVER; i++) ..

with i declared within the routine (i.e., function) with:

for (int i=0; i<WHATEVER; i++) ...

---Jan

Re: G++ 4.3.4 vs.G++ 4.5.2???

[Jonathan Wakely]

On 13 June 2011 11:24, Jan Chludzinski wrote:
> Just finished compiling some numerical code (developed using the
> Borland C++ compiler) using G++ 4.3.4 (that came with Cygwin 1.7). The
> answers are different from what I get using the Borland compiler
> (circa 2002).  I have known correct answers from some NASA code and
> compare against those.
>
> I've transitioned of late to Code::Blocks using the latest MinGW.
> MinGW comes with G++ 4.5.2.  I compiled using this compiler and it
> once again works (I get the same answers as the NASA code).
>
> Are there known problems with G++ 4.3.4?
>
> BTW, the original code was infinite looping until I replaced the old style:
>
> for (i=0; i<WHATEVER; i++) ..
>
> with i declared within the routine (i.e., function) with:
>
> for (int i=0; i<WHATEVER; i++) ...

Are you using x86? Are you telling the compiler to use SSE registers
for floating point instead of the 387 registers?

Does using "-march=pentium3 -mfpmath=sse" with GCC 4.3.4 give the
expected results?

Re: G++ 4.3.4 vs.G++ 4.5.2???

[Jan Chludzinski]

First, I tried "-march=pentium3 -mfpmath=sse" to no avail - same wrong
answer.  The is a "rigid plate" analysis for a vibration problem.  The
correct answer is the plate lattice damps out at -0.414329 @ ~0.5
seconds.   With G++ 4.3.4 I'm now getting:  -0.43281 @ ~0.9 seconds.

Second, I'm simply compiling the source code using g++ <source-file>,
the only option "-g".

---Jan

On Mon, Jun 13, 2011 at 6:54 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 13 June 2011 11:24, Jan Chludzinski wrote:
>> Just finished compiling some numerical code (developed using the
>> Borland C++ compiler) using G++ 4.3.4 (that came with Cygwin 1.7). The
>> answers are different from what I get using the Borland compiler
>> (circa 2002).  I have known correct answers from some NASA code and
>> compare against those.
>>
>> I've transitioned of late to Code::Blocks using the latest MinGW.
>> MinGW comes with G++ 4.5.2.  I compiled using this compiler and it
>> once again works (I get the same answers as the NASA code).
>>
>> Are there known problems with G++ 4.3.4?
>>
>> BTW, the original code was infinite looping until I replaced the old style:
>>
>> for (i=0; i<WHATEVER; i++) ..
>>
>> with i declared within the routine (i.e., function) with:
>>
>> for (int i=0; i<WHATEVER; i++) ...
>
> Are you using x86? Are you telling the compiler to use SSE registers
> for floating point instead of the 387 registers?
>
> Does using "-march=pentium3 -mfpmath=sse" with GCC 4.3.4 give the
> expected results?
>

Re: G++ 4.3.4 vs.G++ 4.5.2???

[Axel Freyn]

Hi Jan,

On Mon, Jun 13, 2011 at 03:54:51PM -0400, Jan Chludzinski wrote:
> First, I tried "-march=pentium3 -mfpmath=sse" to no avail - same wrong
> answer.  The is a "rigid plate" analysis for a vibration problem.  The
> correct answer is the plate lattice damps out at -0.414329 @ ~0.5
> seconds.   With G++ 4.3.4 I'm now getting:  -0.43281 @ ~0.9 seconds.
> 
> Second, I'm simply compiling the source code using g++ <source-file>,
> the only option "-g".
> 
> ---Jan

> 
> On Mon, Jun 13, 2011 at 6:54 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> > On 13 June 2011 11:24, Jan Chludzinski wrote:
> >> Just finished compiling some numerical code (developed using the
> >> Borland C++ compiler) using G++ 4.3.4 (that came with Cygwin 1.7). The
> >> answers are different from what I get using the Borland compiler
> >> (circa 2002).  I have known correct answers from some NASA code and
> >> compare against those.
> >>
> >> I've transitioned of late to Code::Blocks using the latest MinGW.
> >> MinGW comes with G++ 4.5.2.  I compiled using this compiler and it
> >> once again works (I get the same answers as the NASA code).
> >>
> >> Are there known problems with G++ 4.3.4?

Well, I don't know your code / library but floating point calculations
DO depend on compiler, architecture, compilation flags, optimization,...
(and the moon phase ;-)). And if a library is not written extremely
clean, it's quite easy to introduce numerical instabilities as soon as
the numerics become a bit more complex. (Like Jonathan suggested: On
x86, it's a difference whether numerics are done in the FPU or the SSE
unit -- the FPU uses internally higher precision.)
And to make things worse: floating point results MIGHT even depend on
changes you perform at other places in the code (as this might influence
the compilers optimization behaviour...)

> >>
> >> BTW, the original code was infinite looping until I replaced the old style:
> >>
> >> for (i=0; i<WHATEVER; i++) ..
> >>
> >> with i declared within the routine (i.e., function) with:
> >>
> >> for (int i=0; i<WHATEVER; i++) ...
This part is really strange however: Both should give the same behaviour.
The only reasons I can imagine without knowing the code:
 - the "i" in old-style syntax was no "int", but a different (e.g.
   smaller) type?
 - you have a subtle bug in the code which changes the "old-style i"
   from the loop (e.g. by an invalid pointer): your changed line will
   generate a NEW variable "i", which is valid during the loop only and
   is probably stored at another address in memory
 - there is a bug in gcc

Can you supply a (small) working example which reproduces the problem?

Axel

Re: G++ 4.3.4 vs.G++ 4.5.2???

[Jan Chludzinski]

I'm contracting right now and will try when I have time.  Thanks, Jan

On Tue, Jun 14, 2011 at 5:54 AM, Axel Freyn <axel-freyn@gmx.de> wrote:
> Hi Jan,
>
> On Mon, Jun 13, 2011 at 03:54:51PM -0400, Jan Chludzinski wrote:
>> First, I tried "-march=pentium3 -mfpmath=sse" to no avail - same wrong
>> answer.  The is a "rigid plate" analysis for a vibration problem.  The
>> correct answer is the plate lattice damps out at -0.414329 @ ~0.5
>> seconds.   With G++ 4.3.4 I'm now getting:  -0.43281 @ ~0.9 seconds.
>>
>> Second, I'm simply compiling the source code using g++ <source-file>,
>> the only option "-g".
>>
>> ---Jan
>
>>
>> On Mon, Jun 13, 2011 at 6:54 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> > On 13 June 2011 11:24, Jan Chludzinski wrote:
>> >> Just finished compiling some numerical code (developed using the
>> >> Borland C++ compiler) using G++ 4.3.4 (that came with Cygwin 1.7). The
>> >> answers are different from what I get using the Borland compiler
>> >> (circa 2002).  I have known correct answers from some NASA code and
>> >> compare against those.
>> >>
>> >> I've transitioned of late to Code::Blocks using the latest MinGW.
>> >> MinGW comes with G++ 4.5.2.  I compiled using this compiler and it
>> >> once again works (I get the same answers as the NASA code).
>> >>
>> >> Are there known problems with G++ 4.3.4?
>
> Well, I don't know your code / library but floating point calculations
> DO depend on compiler, architecture, compilation flags, optimization,...
> (and the moon phase ;-)). And if a library is not written extremely
> clean, it's quite easy to introduce numerical instabilities as soon as
> the numerics become a bit more complex. (Like Jonathan suggested: On
> x86, it's a difference whether numerics are done in the FPU or the SSE
> unit -- the FPU uses internally higher precision.)
> And to make things worse: floating point results MIGHT even depend on
> changes you perform at other places in the code (as this might influence
> the compilers optimization behaviour...)
>
>> >>
>> >> BTW, the original code was infinite looping until I replaced the old style:
>> >>
>> >> for (i=0; i<WHATEVER; i++) ..
>> >>
>> >> with i declared within the routine (i.e., function) with:
>> >>
>> >> for (int i=0; i<WHATEVER; i++) ...
> This part is really strange however: Both should give the same behaviour.
> The only reasons I can imagine without knowing the code:
>  - the "i" in old-style syntax was no "int", but a different (e.g.
>   smaller) type?
>  - you have a subtle bug in the code which changes the "old-style i"
>   from the loop (e.g. by an invalid pointer): your changed line will
>   generate a NEW variable "i", which is valid during the loop only and
>   is probably stored at another address in memory
>  - there is a bug in gcc
>
> Can you supply a (small) working example which reproduces the problem?
>
> Axel
>