From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15572 invoked by alias); 5 Aug 2005 16:35:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 15516 invoked by uid 22791); 5 Aug 2005 16:35:23 -0000 Received: from eyesopen.com (HELO www.eyesopen.com) (208.41.78.163) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 05 Aug 2005 16:35:23 +0000 Received: from localhost (roger@localhost) by www.eyesopen.com (8.11.6/8.11.6) with ESMTP id j75GRs111817; Fri, 5 Aug 2005 10:27:55 -0600 Date: Fri, 05 Aug 2005 16:35:00 -0000 From: Roger Sayle To: Diego Novillo cc: gcc@gcc.gnu.org Subject: Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE In-Reply-To: <20050805135953.GA23609@topo.toronto.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-08/txt/msg00176.txt.bz2 Hi Diego, On Fri, 5 Aug 2005, Diego Novillo wrote: > In PR 23046 we ICE inside tree-vrp.c because fold() does not > realize that for > > enum enumtype { ENUM1, ENUM2 } x; > > the predicate 'if (x > 1)' is always false. This causes VRP to > create the impossible range [2, 1] for that predicate. > > While it would be trivial for VRP to paper over this problem, the > real fix should be in fold(). I looked at the logic that detects > these cases and it is fairly convoluted (fold-const.c:9174). > > I'm wondering why doesn't fold() just use TYPE_MAX_VALUE/TYPE_MIN_VALUE > if they're available? I'm trying to remember/find the conclusions of the many discussions on the ranges of enumeral types, that we've had in the past. One of the explanations describing the problems in this area was at http://gcc.gnu.org/ml/gcc-patches/2004-05/msg02002.html There was also a huge thread (famewar?) at the time over the issue which began at http://gcc.gnu.org/ml/gcc/2004-08/msg01129.html One of the fundamental problem/contentious issues was whether GCC guarantees that enumeral variables are always truncated and sign or zero extended when assigned from integers, or whether the optimizers can take advantage of the of the fact that the stored representation is always in its enumerated range. A related discussion can also be found in the thread following http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00968.html Perhaps the issue may now be closer the resolution than in was last time around. But the uneasy "detente" is that the middle-end currently treats enumerated types as having the widths of their machine modes. Perhaps things have now changed significantly since the last time this was discussed, I have no vested interest in one side vs. the other, other than the semantics need to be consistent lest the same kinds of tree-ssa bugs resurface again. I hope this helps. My personal advice, assuming that you're looking for an easy life, is to place the seemingly unnessary consistency checks in VRP. Some of the cases discussed in the above threads might make interesting tests for the VRP code. I'll admit some of this "lore" should be documented, but the issue has never been satisfactorily resolved to everyone's satisfaction, so we keep with the less than idea "status quo". Roger --