From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70764 invoked by alias); 12 Jun 2017 12:28:36 -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 64311 invoked by uid 89); 12 Jun 2017 12:28:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=D*comcast.net, hear X-HELO: mail-ua0-f177.google.com Received: from mail-ua0-f177.google.com (HELO mail-ua0-f177.google.com) (209.85.217.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Jun 2017 12:28:32 +0000 Received: by mail-ua0-f177.google.com with SMTP id m31so56079667uam.1 for ; Mon, 12 Jun 2017 05:28:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=58f6rAjS2ayYTonuR0sFqsgG6O6JqhHsJr4+BUkBkq0=; b=H7jctvxYN6sPA2D0cPnvD6M//6+ZTw2q4lcj7pEwZDSLGlmjjuCpS7Tp0H2i8432JR 99cPThZrnkwM315zL3fKPFBMF5LcQWbQ1uUWu0ubE+SeEIM3gIJSZL39n+O8hR16s35+ AyxJvuI6AEciLBsS+UFATak/ScoAIm40CxMH49Jzqiz0oCHs19Uj+LatvpRYXX7HQ5U9 9YQu7JtI3bOD/Rce1hLH9zTEp6tce+OFjtihksIGJN2hrNiMVRjzN9dnNmrjq+WUAXol /4qMnwR6p/nb7iT2XoWOjsHvMQmIak4UdPnJL66rIjnnrTueJpGlqM+SXQpPIvNfqF4A lfRQ== X-Gm-Message-State: AODbwcDC0d+bZVO0MsDSI3foi2DIVt3ZNGTZWlB/GD1zpan6ifatdOpN Q6UkumiirG/0EykPl3275TmuIJmkF2x9 X-Received: by 10.159.52.70 with SMTP id s6mr26964491uab.8.1497270515212; Mon, 12 Jun 2017 05:28:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.50.131 with HTTP; Mon, 12 Jun 2017 05:28:34 -0700 (PDT) In-Reply-To: <62E9DFA1-67E2-442B-8348-61953EAEC5A9@comcast.net> References: <50077577-1941-e83f-aeb6-e63e1bd2701d@mentor.com> <62E9DFA1-67E2-442B-8348-61953EAEC5A9@comcast.net> From: Christophe Lyon Date: Mon, 12 Jun 2017 12:28:00 -0000 Message-ID: Subject: Re: [PATCH, testsuite] Add effective target stack_size To: Tom de Vries Cc: GCC Patches , Rainer Orth Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00783.txt.bz2 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 fe= w 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 o= ther ways, but the dynamic allocation case I think is relatively poorly han= dled. 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 hav= e any good ideas in this area. Marking large memory test cases with size i= nformation, and then just trimming based upon size was my only thought. No= t 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 imple= ment 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=3D16384, maybe that's too small? Thanks, Christophe