--- Comment #7 from burnus at gcc dot gnu dot org 2009-04-28 19:25 ---
(In reply to comment #6)
> may be interested to RTFM and specially:
>
> -fno-automatic
> -fmax-stack-var-size=n
Well, -fopenmp implies -frecursive and thus the use of the stack. If a function
can never be called in s
--- Comment #6 from dominiq at lps dot ens dot fr 2009-04-28 15:19 ---
On darwin I never found a way to increase the stack size above 65532kbytes, you
may be interested to RTFM and specially:
-fno-automatic
Treat each program unit (except those marked as RECURSIVE) as if the SAVE
statem
--- Comment #5 from KnowlesPJ at Cardiff dot ac dot uk 2009-04-28 14:53
---
O, now I see my stupidity, as for some reason ulimit -s is set to a pathetic
8192k. I am sorry to have troubled you folks with this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39945
--- Comment #4 from dominiq at lps dot ens dot fr 2009-04-28 14:39 ---
Works for me on powerpc-apple-darwin9 (OSX 10.5.6). What 'ulimit -a' reports
for "stack size"?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39945
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-28 14:34 ---
This is by design, large arrays usually have an implict SAVE on them, though
with -fopenmp, they don't.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from KnowlesPJ at Cardiff dot ac dot uk 2009-04-28 14:32
---
$ gfortran -v
Using built-in specs.
Target: i386-apple-darwin9.2.2
Configured with: ../configure --prefix=/opt/gcc --with-languages=c,fortran
Thread model: posix
gcc version 4.4.0 20080424 (experimental) (GCC)
--- Comment #1 from KnowlesPJ at Cardiff dot ac dot uk 2009-04-28 14:30
---
Created an attachment (id=17774)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17774&action=view)
sample source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39945
