This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PR 23046. Folding predicates involvingTYPE_MAX_VALUE/TYPE_MIN_VALUE
- From: Jeffrey A Law <law at redhat dot com>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Roger Sayle <roger at eyesopen dot com>, gcc at gcc dot gnu dot org
- Date: Fri, 05 Aug 2005 11:57:45 -0600
- Subject: Re: PR 23046. Folding predicates involvingTYPE_MAX_VALUE/TYPE_MIN_VALUE
- References: <20050805135953.GA23609@topo.toronto.redhat.com>
- Reply-to: law at redhat dot com
On Fri, 2005-08-05 at 09:59 -0400, 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?
IIRC the C standard does not guarantee that an object stay within
the bounds of its enumerated type. You'll have to do some digging
in the relevant standards.
jeff