From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17799 invoked by alias); 9 Mar 2007 14:19:02 -0000 Received: (qmail 17716 invoked by alias); 9 Mar 2007 14:18:43 -0000 Date: Fri, 09 Mar 2007 14:19:00 -0000 Message-ID: <20070309141843.17715.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug ada/26797] [4.3 regression] ACATS cxh1001 fails In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "kenner at vlsi1 dot ultra dot nyu dot edu" 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: 2007-03/txt/msg00736.txt.bz2 ------- Comment #35 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-09 14:18 ------- Subject: Re: [4.3 regression] ACATS cxh1001 fails > All the mess would be way easier if the FE would not expose the subtypes to > the middle-end... I don't see how giving *additional* information could be bad: the middle-end is certainly free to ignore the bounds if it wants to! The point is that the bounds *do* say something and provide useful information to optimizers. The problem is that they don't say what the middle-end *wants* them to say! What they *do* mean is that it's a "bounded error" for a variable to have a value outside of the given bounds. What the middle-end *wants* them to mean is that it's *erroneous* for a variable to have a value outside of the given bounds. We need to reconcile those two concepts. >>From a pragmatic point of view, they aren't that different, but there are a couple of important exceptions. The array bound on the LHS is one of them. A full solution to this is complex, but is indeed something that I'd like to happen some day. It involves work in various places. One thing that would help is that many variables can be proven to have the property that the only way they can have an invalid value is if erroneous behavior has occurred. For such variables, the meaning of the bounds is precisely what the middle-end expects it to mean. The most common case where you can't do this is for component references or pointer dereferences. In that case, we have to address this by distinguishing between two types of tests, those that will just propagate the bounded error condition and those that would convert a bounded error to erroneous behavior. We are allowed to use the bounds information in reasoning about the former, but not the latter. Note that there are similarities to the signed-overflow case here: there are some tests that we can safely eliminate with knowlege that signed-overflow is undefined, but others that we don't want to. So I think the "final" solution here will be to have the Ada front end provide the flag information on variables and tests mentioned above and extend VRP to use them. One of the two front-end issues (the latter) is quite easy and I think the other is moderately-easy. I don't know how much work the required VRP changes would be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797