Eugéne Suter wrote: > snipped, as much rambling stuff as the following reply: I hesitate to respond, as I can see reasons for Tbird to be putting you in the spam box. I don't see this as the place for advice on how to learn about the stack size adjustment of a self built kernel. If you are using the Intel OpenMP library (with a kernel it was not intended to be used with), that also is a responsibility you have taken on yourself which seems off topic here. I do use the Intel library with gomp, but avoid using its special features or non-mainstream kernel builds. That said, KMP_STACKSIZE adjusts the thread stack. Intel libiomp should start it out at 4MB (on x86_64); 2MB on a normal 32-bit kernel. You might want to check it, to see whether it is getting along with your kernel in that respect. No reasonable basic test program should run into any difficulty with default thread stack setting, even on 32-bit Windows. Thread stack is distinct from main program stack, which would be dealt with by ulimit, if that fits with the shell you are using. Am I assuming too much to think that you would have checked ulimit to see if it responded to your setting? I note that the example you quote doesn't USE OMP_LIB, as it should, if you are using a version of gfortran which has implemented the required standard include files. I've heard there is a plan to fix this for next release. If you take their example to imply that libgomp understands the same environment variables as libiomp, that also is an indication that you have too much faith in them and their clairvoyance. In 2004, llnl would not have wanted to support gomp on their system, and would not have considered whether libgomp was planning to adopt Intel extensions. Those examples should at least educate you about which ways you could be requiring abnormally large thread stacks. If you had a question specifically about gfortran, fortran@xxxxxxxxxxx might be a good resource. It's not clear that you do, however. It would be good to search the archives for posts which might be relevant.
