From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16664 invoked by alias); 17 Nov 2009 15:50:29 -0000 Received: (qmail 16648 invoked by uid 22791); 17 Nov 2009 15:50:28 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (212.99.106.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Nov 2009 15:49:25 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 27AFF290033; Tue, 17 Nov 2009 16:49:23 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErWcR3Ct22EB; Tue, 17 Nov 2009 16:49:22 +0100 (CET) Received: from province.act-europe.fr (province.act-europe.fr [10.10.0.214]) by mel.act-europe.fr (Postfix) with ESMTP id 864D729000C; Tue, 17 Nov 2009 16:49:22 +0100 (CET) Received: by province.act-europe.fr (Postfix, from userid 525) id 7BCF816501F; Tue, 17 Nov 2009 16:49:22 +0100 (CET) Date: Tue, 17 Nov 2009 15:50:00 -0000 From: Arnaud Charlet To: rguenther at suse dot de Cc: gcc-bugs@gcc.gnu.org Subject: Re: [Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code Message-ID: <20091117154922.GC38721@adacore.com> References: <20091117150752.26985.qmail@sourceware.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091117150752.26985.qmail@sourceware.org> User-Agent: Mutt/1.5.17 (2007-11-01) Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg01401.txt.bz2 > > Is there anyway for the optimizers to get at this range information still? > > Or was range information removed because it is essentially impossible to use > > it correctly (if so this bug report should be closed as unfixable)? > > It was removed because it was impossible to use it correctly. The "fix" > is to derive range information from existing range checks, possibly > inter-procedurally. Right, as soon as you have one range check, the compiler can make more precise assumptions/conclusions about the actual range. Arno