This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: G++ 4.3.4 vs.G++ 4.5.2???
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
>