This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, testsuite] Add effective target stack_size
- From: Christophe Lyon <christophe dot lyon at linaro dot org>
- To: Tom de Vries <Tom_deVries at mentor dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Rainer Orth <ro at cebitec dot uni-bielefeld dot de>
- Date: Mon, 12 Jun 2017 14:28:34 +0200
- Subject: Re: [PATCH, testsuite] Add effective target stack_size
- Authentication-results: sourceware.org; auth=none
- References: <50077577-1941-e83f-aeb6-e63e1bd2701d@mentor.com> <62E9DFA1-67E2-442B-8348-61953EAEC5A9@comcast.net>
Hi Tom,
On 9 June 2017 at 17:25, Mike Stump <mikestump@comcast.net> wrote:
> On Jun 9, 2017, at 7:24 AM, Tom de Vries <Tom_deVries@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