From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6354 invoked by alias); 21 Aug 2012 11:12:50 -0000 Received: (qmail 6343 invoked by uid 22791); 21 Aug 2012 11:12:49 -0000 X-SWARE-Spam-Status: No, hits=-7.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,MAY_BE_FORGED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 21 Aug 2012 11:12:27 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q7LBCRYF000492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 21 Aug 2012 07:12:27 -0400 Received: from spoyarek (dhcp223-8.pnq.redhat.com [10.65.223.8] (may be forged)) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q7LBCPXT021742 for ; Tue, 21 Aug 2012 07:12:26 -0400 Date: Tue, 21 Aug 2012 11:12:00 -0000 From: Siddhesh Poyarekar To: gdb-patches@sourceware.org Subject: Re: [PATCH] Expand fortran array bounds sizes to LONGEST Message-ID: <20120821164151.0e69b8e8@spoyarek> In-Reply-To: <20120821152540.013b4d99@spoyarek> References: <20120821152540.013b4d99@spoyarek> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-08/txt/msg00565.txt.bz2 On Tue, 21 Aug 2012 15:25:40 +0530, Siddhesh wrote: > Range bounds for a gdb type can have LONGEST values for low and high > bounds. Fortran range bounds functions however use only int. The > larger ranges don't compile by default on gcc, but it is possible to > override the check in the compiler by using -fno-range-check. As a > result, this check is necessary so that we don't print junk in case > of an overflow. Sorry, I forgot to mention that this goes on top of the bitpos patch since it needs some changes from the bitpos patch as well. Regards, Siddhesh