From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75846 invoked by alias); 9 Nov 2016 02:47:10 -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 75826 invoked by uid 89); 9 Nov 2016 02:47:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=f6 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; Wed, 09 Nov 2016 02:46:58 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1c4Iuf-0004Hy-2Y from joseph_myers@mentor.com ; Tue, 08 Nov 2016 18:46:57 -0800 Received: from digraph.polyomino.org.uk (137.202.0.87) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 9 Nov 2016 02:46:53 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.86_2) (envelope-from ) id 1c4IuX-0005Xd-QD; Wed, 09 Nov 2016 02:46:49 +0000 Date: Wed, 09 Nov 2016 02:47:00 -0000 From: Joseph Myers To: James Greenhalgh CC: , Subject: Re: [Patch 6/11] Migrate excess precision logic to use TARGET_EXCESS_PRECISION In-Reply-To: <1478108288-31361-1-git-send-email-james.greenhalgh@arm.com> Message-ID: References: <1478108288-31361-1-git-send-email-james.greenhalgh@arm.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2016-11/txt/msg00784.txt.bz2 On Wed, 2 Nov 2016, James Greenhalgh wrote: > OK, I've reworked the patch along those lines. I noticed that the original > logic looked for > > && TARGET_FLT_EVAL_METHOD != 0 > > And I no longer make that check. Is that something I need to reinstate? No, the replacement logic should imply that previously supported cases with TARGET_FLT_EVAL_METHOD == 0 will pass as being IEEE-compatible. > I didn't find any reference to excess precision in Annex F, so I'd guess > not? There are references, e.g. F.6 requiring that the return statement removes excess precision (but that's something done in the front end, nothing to do with this patch). > diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h > index 547bab2..507967d 100644 > --- a/gcc/c-family/c-common.h > +++ b/gcc/c-family/c-common.h > @@ -1314,6 +1314,8 @@ c_tree_chain_next (tree t) > #define TM_STMT_ATTR_ATOMIC 4 > #define TM_STMT_ATTR_RELAXED 8 > > +extern int parse_tm_stmt_attr (tree, int); > + > /* Mask used by tm_attr_to_mask and tm_mask_to_attr. Note that these > are ordered specifically such that more restrictive attributes are > at lower bit positions. This fact is known by the C++ tm attribute > @@ -1325,6 +1327,10 @@ c_tree_chain_next (tree t) > #define TM_ATTR_IRREVOCABLE 8 > #define TM_ATTR_MAY_CANCEL_OUTER 16 > > +extern int tm_attr_to_mask (tree); > +extern tree tm_mask_to_attr (int); > +extern tree find_tm_attribute (tree); > + > /* A suffix-identifier value doublet that represents user-defined literals > for C++-0x. */ > enum overflow_type { These changes to c-common.h are nothing to do with the subject of the patch. The patch is OK with those changes removed. If there are other changes in this series still needing review, please repost the whole series identifying what patches still need review. (I think the ARM _Float16 support still needs the testsuite changes to ensure that architecture-specific options to enable _FloatN / _FloatNx support are used when testing if the types are supported, so that the _Float16 tests are actually run in that case.) -- Joseph S. Myers joseph@codesourcery.com