From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42890 invoked by alias); 12 Jun 2017 14:29:08 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 42669 invoked by uid 89); 12 Jun 2017 14:29:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=activated, quo X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Jun 2017 14:29:05 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1dKQL4-0002pS-Fx from Tom_deVries@mentor.com ; Mon, 12 Jun 2017 07:29:06 -0700 Received: from [127.0.0.1] (137.202.0.87) by svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 12 Jun 2017 15:29:01 +0100 Subject: Re: [PATCH, testsuite] Add effective target stack_size To: Christophe Lyon CC: GCC Patches , Rainer Orth References: <50077577-1941-e83f-aeb6-e63e1bd2701d@mentor.com> <62E9DFA1-67E2-442B-8348-61953EAEC5A9@comcast.net> From: Tom de Vries Message-ID: <6521e32f-83ce-bc48-f371-8324228c467e@mentor.com> Date: Mon, 12 Jun 2017 14:29:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) X-SW-Source: 2017-06/txt/msg00802.txt.bz2 On 06/12/2017 02:28 PM, Christophe Lyon wrote: > Hi Tom, > > On 9 June 2017 at 17:25, Mike Stump wrote: >> On Jun 9, 2017, at 7:24 AM, Tom de Vries 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? I think that what's going on is the following: - your board description file for aarch64 and arm bare-metal sets gcc,stack_size - before I committed the patch, STACK_SIZE was not defined when compiling this testcase, because the activated .exp files do not define it - after I committed the patch, STACK_SIZE started to be defined, and the test started to fail I'm not sure if this test was ever compiled with STACK_SIZE defined. Either way, the test-case uses the presence of STACK_SIZE, not the actual value, so changing the value of gcc,stack_size won't make a difference. Ideally you'd find out what the exact reason for the failure is, and update the test-case accordingly. The easiest thing we can do is to remove the STACK_SIZE setting in the test-case (and to avoid confusion, remove all the dead STACK_SIZE-enabled code), which returns the status quo of before the patch. Thanks, - Tom