Prev: Allocatable versus automatic arrays
Next: many runs in one directory
From: robin on 2 Jun 2010 22:02
"Arjan" <arjan.van.dijk(a)rivm.nl> wrote in message
news:dc02a4af-999d-4aef-ad25-daa45759c452(a)o39g2000vbd.googlegroups.com...

|I compiled my code with ifort 11.0 under linux.
| All goes well when I use the following parameters at compilation to
| get a debuggable program:
| -g -debug -C -traceback -assume byterecl
| The same run crashes when I use optimization:
| -fast -assume byterecl
| To narrow down to the problem, I added some write-statements.
| The crash vanished...

This sounds like your code has not been debugged.
When putting in or removing statements causes the
program to crash / not crash -- that usually means
that you havs a subscript that is out of bounds,
or other similar problem.

You need to compile the program and run it
with all checks on, and to debug it fully.


From: Arjan on 3 Jun 2010 08:17
When I use g95 with all critical compile switches active to trap as
many errors as possible, the code is slow but runs well.

Changing -fast into -O does not make a difference with ifort.

I'm continuing my quest...

A.
From: Louis Krupp on 3 Jun 2010 13:22
On 6/3/2010 6:17 AM, Arjan wrote:
> When I use g95 with all critical compile switches active to trap as
> many errors as possible, the code is slow but runs well.
>
> Changing -fast into -O does not make a difference with ifort.
>
> I'm continuing my quest...

Will ifort let you compile with "-fast -assume byterecl -g -debug"? If
so, does it still crash? If it does, then it sounds like it might be
time to run the debugger with some optimized code. This can be
difficult, but it's usually not impossible. You might be able to debug
even without "-g" and/or "-debug".

Stupid question: Do you have any subprograms that don't use modules?
Could there be any argument mismatches? I would eliminate those first
if possible.

Louis
First  |  Prev  | 
Pages: 1 2
Prev: Allocatable versus automatic arrays
Next: many runs in one directory