From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1143 invoked by alias); 25 Nov 2010 17:03:26 -0000 Received: (qmail 1129 invoked by uid 22791); 25 Nov 2010 17:03:25 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from troutmask.apl.washington.edu (HELO troutmask.apl.washington.edu) (128.208.78.105) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 25 Nov 2010 17:03:20 +0000 Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id oAPH3Ik3007942; Thu, 25 Nov 2010 09:03:18 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id oAPH3IZ4007941; Thu, 25 Nov 2010 09:03:18 -0800 (PST) (envelope-from sgk) Date: Thu, 25 Nov 2010 18:41:00 -0000 From: Steve Kargl To: "Davis, Jimmie" Cc: "fortran@gcc.gnu.org" , "gcc-patches@gcc.gnu.org" Subject: Re: more fortran test case(s) Message-ID: <20101125170318.GC7832@troutmask.apl.washington.edu> References: <00061D6890083E418784FC390A35E43701D49D@SXMB1PG.SYSTEMS.SMU.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00061D6890083E418784FC390A35E43701D49D@SXMB1PG.SYSTEMS.SMU.EDU> User-Agent: Mutt/1.4.2.3i 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 X-SW-Source: 2010-11/txt/msg02555.txt.bz2 On Sat, Nov 20, 2010 at 01:44:15AM +0000, Davis, Jimmie wrote: > Here are two more test cases provided for the intent of increasing > our test suite coverage. > > I think one of them points to a defect, while using the flag > -fno-range-check we are creating an integer divide with a result > of NaaN to be an error. real and complex in the same situation > store the NaaN and go on. If someone agrees (perhaps who uses > the -fno-range-check compiler option), I would be happy to open > up a PR and submit the rather trivial patch. > Bud, I think that there is ia fundamental difference here. A NaN for real and complex can be naturally stored in the floating representation, so continuing makes some sense. IEEE 754 also defined arithmetic operations involving an NaN. For integer divide by zero, there isn't a bit pattern available to encode an integer NaN. I think that we do not need to do anything special here with -fno-range-check. This option already asks gfortran to violate the standard, so the user should be prepared to get what gfortran generates. -- Steve