public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Axel Freyn <axel-freyn@gmx.de>
To: Jan Chludzinski <jan.chludzinski@gmail.com>
Cc: Jonathan Wakely <jwakely.gcc@gmail.com>, gcc-help@gcc.gnu.org
Subject: Re: G++ 4.3.4 vs.G++ 4.5.2???
Date: Tue, 14 Jun 2011 16:00:00 -0000	[thread overview]
Message-ID: <20110614095409.GA15515@axel> (raw)
In-Reply-To: <BANLkTikzPTCGr6DUrRs030zV1_HDkeJ9eQ@mail.gmail.com>

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

  reply	other threads:[~2011-06-14  9:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-13 12:06 Jan Chludzinski
2011-06-13 16:10 ` Jonathan Wakely
2011-06-13 21:05   ` Jan Chludzinski
2011-06-14 16:00     ` Axel Freyn [this message]
2011-06-14 17:03       ` Jan Chludzinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110614095409.GA15515@axel \
    --to=axel-freyn@gmx.de \
    --cc=gcc-help@gcc.gnu.org \
    --cc=jan.chludzinski@gmail.com \
    --cc=jwakely.gcc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).