fortran optimization errors

Sebastian Sandersius sebastian.sandersius@asu.edu
Fri Jun 22 20:44:00 GMT 2007


Dear Jerry, Steve, Tim and Tobias,

The compiler which is giving all the problems is:
Target: i386-redhat-linux
 gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)

the os is fedora not red hat, in case that may be the problem.

The optimizations I tried were:
(1)    f95 -g semn17.f90 rng.f90 -o n17
(2)    f95 semn17.f90 rng.f90 -o n17
(3)    f95 -O2 semn17.f90 rng.f90 -o n17
(4)    f95 -O3 semn17.f90 rng.f90 -o n17

An example of the numerical output:

(1)     1.032397734218777E-002
(2)     1.032397734218777E-002
(3)     1.035838362773763E-002
(4)     1.035838362773763E-002

so you can see where the discrepancies are.

I can compile and run the same code on my mac:
Target: i386-apple-darwin8.8.1
gcc version 4.3.0 20061230 (experimental)

and there are no discrepancies in the numerical
output no matter what the optimization is:

(1)  1.032407088285647E-002
(2)  1.032407088285647E-002
(3)  1.032407088285647E-002
(4)  1.032407088285647E-002

I hope that answers all your questions for now.

 Regards, Sebastian


On 6/21/07, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
> On Thu, Jun 21, 2007 at 09:21:33PM -0700, Tim Prince wrote:
> > Sebastian Sandersius wrote:
> > >I don't think the code is numerically
> > >unstable because I can run it on my mac and compile it with gfortran
> > >and the numerical output is the same no matter what the optimization
> > >tag is.
> > If you have a mac PPC you don't have an extra precision option such as
> > you do on linux (and -mfpmath=387 is the default for 32-bit linux).
> > It's important for you to quote exact target names and compiler
> > switches.  Commonly used gfortran architecture switches include
> > -march=pentium4 (to cover all SSE2 machines) -mfpmath=sse (to request
> > SSE code rather than x87).  Not everyone would call a code numerically
> > unstable simply because the results are slightly different when you run
> > with extra precision.
>
> In case it wasn't obvious from the terseness of my previous
> reply, I was being sarcastic.  Sebastian's original email reminds
> me of a famous Groucho Marx bit: 'Doctor, it hurts when I
> do this.  (Doctor) Well, don't do it.'
>
> Sebastian has shown no code, no compiler options, and no compiler
> version.  Yet, he's prepared to declare gfortran has errors because
> his code's output changes with changing options.  If his code is
> sensitive to extra precision (hint use -ffloat-store), then his
> code may not be unstable but it is certain not robust (hint
> use -Wall).  The fact that a segfault goes away if he adds a print
> statement suggests he has array indexing problems (hint use
> -fbounds-check).
>
> --
> Steve
>



More information about the Fortran mailing list