Stack size, and warnings [Fortran]

Prev: comment and IBM xlf
Next: text processing

From: Dieter Britz on 28 Sep 2006 09:47

1. My recursive program now runs, but when I increase the size
of the job, I get an "IOT trap", which I am told is likely
to be stack overflow. I am using the Intel 90/95 compiler,
and I work under Suse Linux 10.1. I think I need to write
something into the .bashrc file; what should this be, please?

2. The routine calls itself many times, with array sections
as arguments, and I get a lot of warnings that a temporary
array was allocated. I tried to suppress these with the -w
option, but they don't go away. Why not, and how do I stop
them?
--
Dieter Britz, Kemisk Institut, Aarhus Universitet

From: Rich Townsend on 28 Sep 2006 11:16

From: Fly Away on 28 Sep 2006 15:02

From: Steve Lionel on 28 Sep 2006 15:15

Dieter Britz wrote:

> 2. The routine calls itself many times, with array sections
> as arguments, and I get a lot of warnings that a temporary
> array was allocated. I tried to suppress these with the -w
> option, but they don't go away. Why not, and how do I stop
> them?

Are these warnings coming out at compile time or at run-time? I think
the latter - they are controlled by the "-check arg_temp_created"
option and you may have turned on all run-time checking with -check or
--C.

However, these warnings are giving you a big clue, and rather than try
to suppress them you should try to determine why they are there and how
to rewrite your code to eliminate them.

What is happening is that you are passing a non-contigous array or
array slice to a routine that has either an implicit interface or an
explicit interface where the receiving argument is not an assumed-shape
array. (DIMENSION(:)). In this situation, the compiled code has to
create a contiguous copy of the array slice because the called routine
is expecting a contiguous array.

One solution is to have the called routine accept an assumed-shape
array and provide an explicit interface - then the array will be passed
by descriptor and no copy will need to be made.

Another solution is to see if you really need to be passing a
non-contiguous array here. Note that the compiler will generate
run-time code to test for contiguity if it doesn't know at
compile-time, so you should not get this warning unless the array
really is non-contiguous.

If you take either of these approaches, then the stack temp array will
not be created and your program will use much less stack.

A third option, which I don't recommend unless you have exhausted the
others, and which works only in the latest Intel compiler (9.1.037 on
Linux), is to tell the compiler to allocate array temporaries on the
heap rather than the stack. In 9.1.037, you have to use the
undocumented switch:

-Qoption,f,"-heap_arrays 0"

In future updates, you'll be able to simply use -heap-arrays
(/heap-arrays on Windows).

Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
My Fortran blog
http://www.intel.com/software/drfortran

From: Dieter Britz on 29 Sep 2006 04:00

Dieter Britz wrote:

> 1. My recursive program now runs, but when I increase the size
> of the job, I get an "IOT trap", which I am told is likely
> to be stack overflow. I am using the Intel 90/95 compiler,
> and I work under Suse Linux 10.1. I think I need to write
> something into the .bashrc file; what should this be, please?
>
> 2. The routine calls itself many times, with array sections
> as arguments, and I get a lot of warnings that a temporary
> array was allocated. I tried to suppress these with the -w
> option, but they don't go away. Why not, and how do I stop
> them?

OK, the second point has been answered, I removed the -C
option and I no longer get the warnings.

I tried also to put in the unlimit command, but I still get
the same error, IOT trap. At the same time, I get on the screen
this:

db(a)kembritz:~/tut> *** glibc detected *** ./a.out: corrupted double-linked
list: 0x080af1a8 ***
======= Backtrace: =========
/lib/libc.so.6[0x402aa911]
/lib/libc.so.6[0x402abb70]
/lib/libc.so.6(__libc_free+0x84)[0x402abf84]
../a.out[0x805d650]
../a.out[0x805d5c5]
../a.out[0x804b783]
../a.out[0x804c7e3]
../a.out[0x804bf20]
../a.out[0x804b3a9]
../a.out[0x804c7b8]
../a.out[0x804c7e3]
../a.out[0x804a27f]
../a.out[0x8049d11]
/lib/libc.so.6(__libc_start_main+0xdc)[0x4025c87c]
../a.out[0x8049c51]
======= Memory map: ========
08048000-080a1000 r-xp 00000000 03:05 400599 /home/db/tut/a.out
etc

Is this telling me something besides a stack problem?
--
Dieter Britz, Kemisk Institut, Aarhus Universitet

| Next | Last
Pages: 1 2 3
Prev: comment and IBM xlf
Next: text processing