From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70757 invoked by alias); 27 Nov 2018 09:27:13 -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 70748 invoked by uid 89); 27 Nov 2018 09:27:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=day 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; Tue, 27 Nov 2018 09:27:10 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-MBX-03.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1gRZe6-0006ZZ-V3 from Andrew_Stubbs@mentor.com ; Tue, 27 Nov 2018 01:27:06 -0800 Received: from [172.30.88.209] (137.202.0.90) by SVR-IES-MBX-03.mgc.mentorg.com (139.181.222.3) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 27 Nov 2018 09:27:01 +0000 Subject: Re: [PATCH 10/10] Port testsuite to GCN To: Mike Stump CC: Jeff Law , References: <2d4f15916d3fd76c3c125eca60a86f5be5b807c0.1542381960.git.ams@codesourcery.com> <693FC594-0F70-46AC-916D-C923F966ED1B@comcast.net> <0767D01A-7D1A-4FD0-84C9-47C11DDCC04D@comcast.net> From: Andrew Stubbs Message-ID: <4d565043-980f-bb9a-59cd-76aca5dcf7e7@codesourcery.com> Date: Tue, 27 Nov 2018 09:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <0767D01A-7D1A-4FD0-84C9-47C11DDCC04D@comcast.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-11/txt/msg02170.txt.bz2 On 26/11/2018 21:13, Mike Stump wrote: > On Nov 26, 2018, at 12:04 PM, Mike Stump wrote: >> >> I'll Ok the signal one, if you prefer it over a dummy signal routine. Though, would be nice for you to add signal if possible/reasonable. > > Oh, and my long term thinking on signal is that logically, it's fine to have: > > #if __has_include("signal.h") > signal(...); > #endif > > and once we have a way to do that, then the processor specific test goes away. Over time, it does seem that we add more introspection capabilities to the compiler, and introspection on what headers are there, is pretty basic, so I can see that one day, I expect we'll get support for it. > > Indeed, I was looking at the laundry list of changes a port did recently (effective target changes), and was wondering if all these would be better served by the compiler setting up those values for introspection, and the testsuite using those values from introspection. > > Hum, [ testing ] we already have it, welcome to the future I guess. Could you please use the above form instead? I can't think of any down side to doing it this way. Thanks, I've been meaning to test why we have that, but I'm working on addressing Jeff's review of my other patch right now. I'll do it as you suggest, if I don't find a better way. Andrew