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@xxxxxx> 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@xxxxxxxxx> 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 >
