From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103954 invoked by alias); 17 Jun 2015 10:41:59 -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 102580 invoked by uid 89); 17 Jun 2015 10:41:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (146.101.78.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Jun 2015 10:41:57 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by uk-mta-35.uk.mimecast.lan; Wed, 17 Jun 2015 11:41:55 +0100 Received: from localhost ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2015 11:41:54 +0100 From: Richard Sandiford To: "Maciej W. Rozycki" Mail-Followup-To: "Maciej W. Rozycki" ,Joseph Myers , Steve Ellcey , gcc-patches@gcc.gnu.org, Catherine Moore , Matthew Fortune , richard.sandiford@arm.com Cc: Joseph Myers , Steve Ellcey , gcc-patches@gcc.gnu.org, Catherine Moore , Matthew Fortune Subject: Re: [Patch, MIPS] Enable fp-contract on MIPS and update -mfused-madd In-Reply-To: (Maciej W. Rozycki's message of "Tue, 16 Jun 2015 14:26:40 +0100 (BST)") References: <4c25620c-546c-40ae-b330-3652fe25f791@BAMAIL02.ba.imgtec.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3 (gnu/linux) Date: Wed, 17 Jun 2015 10:43:00 -0000 Message-ID: <87mvzy4nwu.fsf@e105548-lin.cambridge.arm.com> MIME-Version: 1.0 X-MC-Unique: hK8BrQPJQvSF5jGDGA8rKA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-06/txt/msg01188.txt.bz2 "Maciej W. Rozycki" writes: > In that case I think the HONOR_NANS checks will best be globally removed= =20 > first (where applicable of course), with a separate preparatory change. With a comment though :-) I.e. say that although NEG is the IEEE negate operation, we don't need to honour NaNs in the unfused combiner patterns because the rtx operations with which they're being combined don't preserve the signs of NaNs. Thanks, Richard