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