PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE

PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE

[Diego Novillo]

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?


Thanks.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE

[Roger Sayle]

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

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE

[Jeffrey A Law]

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

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Henderson]

On Fri, Aug 05, 2005 at 11:57:45AM -0600, Jeffrey A Law wrote:
> 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.

For the record, I believe we've addressed these issues sometime
within the last year or two.  The TYPE_MIN/MAX_VALUE for an enum
should be set to the range truely required by the relevant language
standards (different between C and C++).

I don't know for a fact that Ada has been adjusted for this though.

The minimum Definitely Correct change at the moment appears to be

-    int width = GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (arg1)));
+    int width = TYPE_PRECISION (TREE_TYPE (arg1));

But if an Ada developer can verify that enumerations are correctly
created, we can delete about 100 lines of code.  Which would be nice.


r~

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Florian Weimer]

* Richard Henderson:

> For the record, I believe we've addressed these issues sometime
> within the last year or two.  The TYPE_MIN/MAX_VALUE for an enum
> should be set to the range truely required by the relevant language
> standards (different between C and C++).
>
> I don't know for a fact that Ada has been adjusted for this though.

From GIGI (around line 4115 in declc):

  if ((kind == E_Enumeration_Type && Present (First_Literal (gnat_entity)))
      || (kind == E_Floating_Point_Type && !Vax_Float (gnat_entity)))
    {
      tree gnu_scalar_type = gnu_type;

      [...]

      TYPE_MIN_VALUE (gnu_scalar_type)
	= gnat_to_gnu (Type_Low_Bound (gnat_entity));
      TYPE_MAX_VALUE (gnu_scalar_type)
	= gnat_to_gnu (Type_High_Bound (gnat_entity));

This is wrong (as discussed before) and is likely the cause of PR21573
(not VRP-related, the expanders for SWITCH_EXPR look at these
attributes, too).  I'm not sure if it is safe to delete these
assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VALUE are used
quite extensively throught GIGI.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Henderson]

On Fri, Aug 05, 2005 at 10:15:04PM +0200, Florian Weimer wrote:
>       TYPE_MIN_VALUE (gnu_scalar_type)
> 	= gnat_to_gnu (Type_Low_Bound (gnat_entity));
>       TYPE_MAX_VALUE (gnu_scalar_type)
> 	= gnat_to_gnu (Type_High_Bound (gnat_entity));
> 
> This is wrong (as discussed before) and is likely the cause of PR21573
> (not VRP-related, the expanders for SWITCH_EXPR look at these
> attributes, too).  I'm not sure if it is safe to delete these
> assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VALUE are used
> quite extensively throught GIGI.

Well, perhaps yes, perhaps no.  What I don't know is if it is
actively illegal to assign 0 to an enumeration that doesn't
contain 0 as a member.

It's clear that if it is in fact illegal, that the Ada front
end has to use some other type than the enumeration to validate
the values going into the enumeration.  Which could be construed
as the case with 21573 -- we should have used an int32_t equivalent
instead of the enumeration.


r~

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Florian Weimer]

* Richard Henderson:

> On Fri, Aug 05, 2005 at 10:15:04PM +0200, Florian Weimer wrote:
>>       TYPE_MIN_VALUE (gnu_scalar_type)
>> 	= gnat_to_gnu (Type_Low_Bound (gnat_entity));
>>       TYPE_MAX_VALUE (gnu_scalar_type)
>> 	= gnat_to_gnu (Type_High_Bound (gnat_entity));
>> 
>> This is wrong (as discussed before) and is likely the cause of PR21573
>> (not VRP-related, the expanders for SWITCH_EXPR look at these
>> attributes, too).  I'm not sure if it is safe to delete these
>> assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VALUE are used
>> quite extensively throught GIGI.
>
> Well, perhaps yes, perhaps no.  What I don't know is if it is
> actively illegal to assign 0 to an enumeration that doesn't
> contain 0 as a member.

Illegal from which viewpoint?  Language definition or GCC optimizers?

> It's clear that if it is in fact illegal, that the Ada front
> end has to use some other type than the enumeration to validate
> the values going into the enumeration.

In the Ada case, all the necessary compile-time checks should be
performed by the front end anyway.