This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: fortran optimization errors
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