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
--
