From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31468 invoked by alias); 11 Sep 2019 20:47:58 -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 31456 invoked by uid 89); 11 Sep 2019 20:47:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 spammy=H*i:sk:3CD73F6, H*f:sk:3CD73F6 X-HELO: aserp2120.oracle.com Received: from aserp2120.oracle.com (HELO aserp2120.oracle.com) (141.146.126.78) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 11 Sep 2019 20:47:56 +0000 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x8BKcnEe093695; Wed, 11 Sep 2019 20:47:53 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : references : date : in-reply-to : message-id : mime-version : content-type; s=corp-2019-08-05; bh=24Ev1C3CsAf2ZaT92+/vwvxcvSfSRT7pkCe9ErlKzqk=; b=OKepXjzZqgwHbMu8zNLu3cd/kzxXyIxNeZx9WwdfiAn8vloNbaSqq+MmISjJtAsziDu/ OdT6BNpXyrpWMe3vd9yzc/Tp7pLw3lc2gIcf69zotjUfBeN+TKQhNxnVyQ7KNgv9FJ/g NoVaNU/bARN6qM5DUYU3QC3FcjAZs/NRVD/fkkUQTZ0xjYmMLovSovTcJ1xq+dbrWLzk mNOMJ+oyRm0b9YKaHTn1dnoVpTpHKl6i9bSkIMBXriMdT+bCFDL2wFNusnrEtoAo5IDj qImJdbw45XgYodz6JvdxCiJS//9LxHZxjsLjurwVCKnNCUGPRlkYO+BHSvuBxRe4jpDP AQ== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 2uw1jycksp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Sep 2019 20:47:53 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x8BKcwVw105265; Wed, 11 Sep 2019 20:47:53 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 2uxj896prc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Sep 2019 20:47:53 +0000 Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x8BKlpq5023176; Wed, 11 Sep 2019 20:47:52 GMT Received: from termi.oracle.com (/62.28.66.22) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Sep 2019 13:47:51 -0700 From: jose.marchesi@oracle.com (Jose E. Marchesi) To: Mike Stump Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH V6 04/11] testsuite: new require effective target indirect_calls References: <20190829151347.13536-1-jose.marchesi@oracle.com> <20190829151347.13536-5-jose.marchesi@oracle.com> <3CD73F6C-7900-48E5-95DA-345E5884AE00@comcast.net> Date: Wed, 11 Sep 2019 20:47:00 -0000 In-Reply-To: <3CD73F6C-7900-48E5-95DA-345E5884AE00@comcast.net> (Mike Stump's message of "Wed, 11 Sep 2019 11:55:17 -0700") Message-ID: <87blvqlfv0.fsf@oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00816.txt.bz2 Hi Mike. Thanks for the review. On Aug 29, 2019, at 8:13 AM, Jose E. Marchesi wrote: > > This patch adds a new dg_require_effective_target procedure to the > testsuite infrastructure: indirect_calls. This new function tells > whether a target supports calls to non-constant call targets. Ok. I'll let people contemplate some comments... I'm torn between targets that can't support C and gooping up the test suite and approving. I'll error on the side of approving this, but, would like to hear from folks if I go to far. Since they are easy to identify, maintain and ignore... I went with approval. People can contemplate other ways to do this, like introduce a fake marker for when the feature is used and when running a program with such a marker, then mark it as unsupported. This way, no test need be marked, and all future test cases that use the feature, just flip to unsupported, no maintenance required. We do this sort of thing with programs that overflow the RAM, by using a stylized error message from ld, and noticing that in dejagnu, and then not expecting it to work. If you can find a way to tally stack space, and check it before running it, the other change to tightly track stack space then would not be as necessary. I think you might be able to do this on your target. Having the stack space marked is generally useful for other targets, as most won't have a nice way to sort out small stacks, so my general comment apply less to the stack size, but, things that can cause you less maintenance burden are likely good in any event. I am working on a new compilation mode for what I call xbpf, which is basically eBPF plus extensions to eliminate the current restrictions to C. The purpose of -mxbpf is mainly to test the compiler. Once the support is in, I will revert this and similar other patches. J.