From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64236 invoked by alias); 5 Dec 2019 16:06:05 -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 64221 invoked by uid 89); 5 Dec 2019 16:06:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:6DF8E0E, H*MI:sk:6DF8E0E, H*f:sk:6DF8E0E X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Dec 2019 16:06:00 +0000 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xB5G5lnx013649; Thu, 5 Dec 2019 11:05:58 -0500 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 2wq1kyb1wx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Dec 2019 11:05:57 -0500 Received: from m0098399.ppops.net (m0098399.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id xB5G5s33016109; Thu, 5 Dec 2019 11:05:54 -0500 Received: from ppma02wdc.us.ibm.com (aa.5b.37a9.ip4.static.sl-reverse.com [169.55.91.170]) by mx0a-001b2d01.pphosted.com with ESMTP id 2wq1kyb1ns-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Dec 2019 11:05:53 -0500 Received: from pps.filterd (ppma02wdc.us.ibm.com [127.0.0.1]) by ppma02wdc.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id xB5G50At019181; Thu, 5 Dec 2019 16:05:48 GMT Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by ppma02wdc.us.ibm.com with ESMTP id 2wkg27qwhe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Dec 2019 16:05:48 +0000 Received: from b03ledav002.gho.boulder.ibm.com (b03ledav002.gho.boulder.ibm.com [9.17.130.233]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id xB5G5lji61735260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 5 Dec 2019 16:05:47 GMT Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1A6D8136051; Thu, 5 Dec 2019 16:05:47 +0000 (GMT) Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 66B02136066; Thu, 5 Dec 2019 16:05:46 +0000 (GMT) Received: from [9.160.43.33] (unknown [9.160.43.33]) by b03ledav002.gho.boulder.ibm.com (Postfix) with ESMTP; Thu, 5 Dec 2019 16:05:46 +0000 (GMT) Subject: Re: [PATCH] rs6000: Fix 2 for PR92661, Do not define builtins that overload disabled builtins To: Iain Sandoe , Segher Boessenkool Cc: GCC Patches , David Edelsohn References: <6129bc8a-18f3-3c25-22c0-f26e4358c5b3@linux.ibm.com> <20191204191641.GA3152@gate.crashing.org> <4e90e982-6153-0009-c557-f963f41a0427@linux.ibm.com> <20191204205057.GC3152@gate.crashing.org> <49f70c63-5733-d2a5-6433-807c2663826e@linux.ibm.com> <20191204230331.GG3152@gate.crashing.org> <6DF8E0E8-61D3-42AB-A736-A75FD1092A7C@sandoe-acoustics.co.uk> From: Peter Bergner Message-ID: <3eac04bd-5b5f-6be3-6bd3-621b90aedbd3@linux.ibm.com> Date: Thu, 05 Dec 2019 16:06:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <6DF8E0E8-61D3-42AB-A736-A75FD1092A7C@sandoe-acoustics.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00337.txt.bz2 On 12/5/19 2:44 AM, Iain Sandoe wrote: > Segher Boessenkool wrote: >> On Wed, Dec 04, 2019 at 03:53:30PM -0600, Peter Bergner wrote: >>> Sure, I can add a test in gcc.target/powerpc/ that uses both a builtin >>> and an overloaded builtin to make sure we don't ICE when DFP is disabled. >> >> Great, thanks! > > so that would be a/some dg-do compile test(s), then? > (presumably, gated on effective_target_dfp … see below) Yes, only a dg-do compile test. For DFP enabled targets, they shouldn't see any errors at all and for DFP disabled targets, I'd insert some dg-error checks gated on ![check_effective_target_dfp] looking for the "error: decimal floating-point not supported for this target" errors. Any ICE would flag a real test case error. > (on r278957, with the system assembler which doesn’t support DFP insns > and gcc.target dfp.exp not yet renamed) > > # Skip these tests for targets that don't support this extension. > if { ![check_effective_target_dfp] } { > return; > } > > Works on Darwin to skip the entire set (not too much of a surprise, since > it’s used for the GCC and G++ cases already). Great, thanks for checking. > It’s possible (even likely) that Darwin can be built with an assembler that > supports DFP instructions, even tho it has no OS support. Usually, my policy > is that we would do compile tests then, since that excercises more code. My --disable-decimal-float run also worked and I had an assembler that supports all of the DFP insns, so I'd expect it to work for you too. The check_effective_target_dfp tests really is checking for whether the DFP modes exist in the compiler and that isn't gated on the assembler... at least fully. > ..but then we need to gate run tests on the availability of runtime support. There exists check_effective_target_dfprt for that. > I see that the GCC and G++ testsuites have also…. > > # If the decimal float is supported in the compiler but not yet in the > # runtime, treat all tests as compile-only. > global dg-do-what-default > set save-dg-do-what-default ${dg-do-what-default} > if { ![check_effective_target_dfprt] } { > verbose "dfp.exp: runtime support for decimal float does not exist" 2 > set dg-do-what-default compile > } else { > verbose "dfp.exp: runtime support for decimal float exists, use it" 2 > set dg-do-what-default run > } > verbose "dfp.exp: dg-do-what-default is ${dg-do-what-default}” 2 > > Do you think there’s any merit in doing something like that here too? Adding this to powerpc/dfp/dfp.exp won't do anything, since all of the powerpc/dfp/ tests are dg-do compile tests. > (I guess a finer-grained alternative is check_effective_target_dfprt in any > run-tests) > > .. or I can just force a false return from effective_target_dfp as we > do for other cases where assembler support does not imply system > support. I've already verified that if decimal float is disabled, but you do have an assembler that supports dfp insns, check_effective_target_dfp still works correctly. Peter