stack size limits?

[timconnors]

In: Intel Fortran Compiler for 32-bit applications, Version 8.0 Build 20040412Z Package ID: l_fc_pc_8.0.046

I have a peice of code that was working in v 7.0:

  SUBROUTINE regrid2dREAL(blank,invalid,scale,unlogify, &
       x1i,x2i,y1i,y2i,xl,xh,yl,yh,pdxi,pdyi, &
       x1o,x2o,y1o,y2o,pdxo,pdyo, arrayi, arrayo)

    .....

    DOUBLE PRECISION, INTENT(IN) :: arrayi(:,:)
    REAL,             INTENT(INOUT):: arrayo(:,:)

    DOUBLE PRECISION, ALLOCATABLE :: weights(:,:)

    ALLOCATE(weights(x1o:x2o,y1o:y2o),STAT=status)

When the weights array was explicitly on the stack, and was dimensioned x1o:x2o,y1o:y2o, the program would segfault immediately upon entry to regrid2dREAL. I got around this eventaully, once I worked out what was happening, by allocating it manually as in the above code snippet. This array is not very big - currently 823x823 elements, ie, only a few meg -- I experimentally determined that an array ~ 3/4*3/4 as big as this was fine. Soon, I will want to write the 3D analogue of this, in which case I will seriously be straining the stack if I try to do the same thing.

Bash tells me via ulimit that my stack size is unlimited. What gives? Does ifort have an accidental stack size limit now?

[TimP]

Message Edited by tim18 on 08-25-2004 03:50 PM

[timconnors]

---

tcprince wrote:

Since you don't give much information, I'll remind you that a typical thread stack size limit for static links with glibc is 2MB. As I understand it, 7.1 over-rode -static for the thread library link. Why do you think premier.intel.com reports require information such as your kernel and glibc, and the compiler options employed?

---

OK. kernel is a SuSE 2.4.20 kernel. Glibc is 2.3.2-6.

I thought I had included the compiler flags. I'm currently using

ifort -u -nbs -tpp7 -axW -fno-alias -ansi_alias -ip -align -warn all -traceback -O2 -o plotmomentmaps.o -c plotmomentmaps.f90

and

ifort -u -nbs -tpp7 -axW -fno-alias -ansi_alias -ip -align -warn all -traceback -O0 -C -o plotmomentmaps.go -c plotmomentmaps.f90

the latter for my debugging versio - both crash in the same way

I thought stack sizes for threads were irrelevant (particularly since the man page states -nothreads is the default) - I'm not doing anything multithreaded. But that 2MB limit would be my problem - thanks for letting me know.

As to premier.intel.com - I don't have a login for that (I could grab one off the support guys here, but haven't done so yet), and the link in the "welcome to the forum" post is somewhat broken for any browsers I am liable to be able to use under Linux.

[Steven_L_Intel1]

How is the link broken?

[timconnors]

---

sblionel wrote:

How is the link broken?

---

I would have to say "it's not".

Heh. Up until yesterday, it was displaying the first menu item from the left, and a menu item across the top, but nothing else.

I haven't done any upgrading on my end, so it's not a mozilla upgrade or something, so I'll just put this one into the "mystery" bucket.

BTW - do intel check their webpages with some sort of w3c validator?

[timconnors]

I see now that

http://support.intel.com/support/performancetools/fortran/sb/CS-007790.htm

talks about the stack size issue. The suggestion to use ulimit -s unlimited is what I already have, and doesn't fix the problem.

The thread issue tcprince mentioned - are there compiler flags thatI could use to check his theory?

[TimP]

If your problem is with the thread stack size limit, linking dynamically against the thread libraries should allow your shell or environment stack limits settings to take effect.If you want more expert advice about this, you might ask on the threading forum, after reading http://www.intel.com/software/products/compilers/clin/relnotes.pdf