From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26502 invoked by alias); 30 Mar 2008 09:15:53 -0000 Received: (qmail 26284 invoked by uid 48); 30 Mar 2008 09:15:04 -0000 Date: Sun, 30 Mar 2008 09:15:00 -0000 Message-ID: <20080330091504.26283.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "ebotcazou at gcc dot gnu dot org" 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: 2008-03/txt/msg02424.txt.bz2 ------- Comment #53 from ebotcazou at gcc dot gnu dot org 2008-03-30 09:15 ------- I should have been more careful, there are wrong premises: > Yes. Amazing, isn't it ;) The important thing to keep in mind is that > all "target" variables must be in the range 10..20, and all "source" > variables in the range 0..100 (see the definitions > type S is range 0 .. 100; <-- S corresponds to Source_Type in Join_Equal > type T is range 10 .. 20; <-- T corresponds to Target_Type in Join_Equal > ). > What does "must be in the range" mean? Firstly, the program behaviour is > undefined if a variable is outside its range. That's not true. The reference to an invalid value doesn't result in undefined behavior, it is a bounded error, and the result must be some predictable non-erroneous implementation-defined behavior. > Secondly, the language requires the compiler to check at the point of the > call that the values passed to the Join_Equal subprogram are in the right > ranges. There is no such requirement and GNAT doesn't do that by default, you need to pass -gnatVi on the command line to activate validity check for in arguments. > Anyway, the practical upshot is that VRP is allowed to assume that > source_first and source_last have values in the range 0..100, and > target_first and target_last have values in the range 10..20. Using > this, it should be able to eliminate all of the compiler inserted range > checking. Since the premises are wrong, the conclusion doesn't hold. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911