From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25473 invoked by alias); 6 Aug 2007 18:16:47 -0000 Received: (qmail 25406 invoked by uid 22791); 6 Aug 2007 18:16:44 -0000 X-Spam-Check-By: sourceware.org Received: from zs01.physik.fu-berlin.de (HELO zs01.physik.fu-berlin.de) (160.45.35.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 06 Aug 2007 18:16:35 +0000 Received: from ith.physik.fu-berlin.de ([160.45.32.115] helo=[127.0.0.1]) by zs01.physik.fu-berlin.de with esmtp (Exim 4.63) (envelope-from ) id 1II782-000077-65; Mon, 06 Aug 2007 20:16:32 +0200 Message-ID: <46B7657F.2070204@net-b.de> Date: Mon, 06 Aug 2007 18:16:00 -0000 From: Tobias Burnus User-Agent: Thunderbird 2.0.0.4 (X11/20070613) MIME-Version: 1.0 To: "'fortran@gcc.gnu.org'" , gcc-patches Subject: [Fortran, patch] PR33001 - Point to -fno-range-check Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-ZEDV-Virus-Scanned: No viruses found. [Could not determine clamav version] X-ZEDV-Spam-Level: ---- X-ZEDV-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on zs01.physik.fu-berlin.de X-ZEDV-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.7-deb X-ZEDV-Spam-Report: * -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.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 X-SW-Source: 2007-08/txt/msg00374.txt.bz2 :ADDPATCH fortran: Currently, we have in primary.c: if (gfc_range_check (e) != ARITH_OK) { gfc_error ("Integer too big for its kind at %C. This check can be " "disabled with the option -fno-range-check"); As the same problem can also occur with BOZ in DATA statements, I would suggested to apply the following patch. Test case: INTEGER LARGE(2) DATA LARGE(1), LARGE(2) / Z'FFFFFFFF', Z'7FEFFFFF' / 1 Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1) The error is correct, however, if the overflow is intended, then -fno-bounds-check has to be used. As it is not obvious that such an option exists, I think one should point to that flag in the error message. Hopeful this will reduce the number of such bug reports and help increase with user satisfaction. The following patch was build & regression tested on x86_64. Ok for the trunk? Tobias Index: gcc/fortran/arith.c =================================================================== --- gcc/fortran/arith.c (Revision 127246) +++ gcc/fortran/arith.c (Arbeitskopie) @@ -1981,7 +1981,8 @@ arith_error (arith rc, gfc_typespec *fro gfc_typename (from), gfc_typename (to), where); break; case ARITH_OVERFLOW: - gfc_error ("Arithmetic overflow converting %s to %s at %L", + gfc_error ("Arithmetic overflow converting %s to %s at %L. This check " + "can be disabled with the option -fno-range-check", gfc_typename (from), gfc_typename (to), where); break; case ARITH_UNDERFLOW: