Hi Tom, On 9 June 2017 at 17:25, Mike Stump <mikest...@comcast.net> wrote: > On Jun 9, 2017, at 7:24 AM, Tom de Vries <tom_devr...@mentor.com> wrote: >> this patch adds effective target stack_size. > >> OK for trunk if x86_64 and nvptx testing succeeds? > > Ok. > > The only last issue in this area that I know about is that there are a few > more test cases that need up to 48 MB to run, the problem is that targets > might have substantially less memory. Stack size is one of the ways this > problem can be exposed. The failure to load case is or can be handled in > other ways, but the dynamic allocation case I think is relatively poorly > handled. On my machine, I just punted by running on a virtual simulator that > I pushed memory up to 48 MB and ignored the issue. If anyone wants to try > their hand at it, I'd be happy to review some patches. For those on demand > virtual memory systems, of course, the problem is invisible. I didn't have > any good ideas in this area. Marking large memory test cases with size > information, and then just trimming based upon size was my only thought. Not > exactly portable, as the exact size of any test case is of course target > dependent; but, if we get close enough, it can provide enough of a solution I > think. > > If people have better ideas in this area, even if you don't want to implement > them, it'd be nice to hear about them.
After this commit (r249090), I've noticed that badalloc1.C fails at execution on aarch64 and arm bare-metal targets. It is compiled with -DSTACK_SIZE=16384, maybe that's too small? Thanks, Christophe
