This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR32628, bogus overflow flag on sizetype consts


On Wed, 16 Jan 2008, Richard Kenner wrote:

> > It's the subtle overflow checking code in the E_Array_Subtype case of 
> > gnat_to_gnu_entity, more specifically:
> > 
> > 	      /* See if the base array type is already flat.  If it is, we
> > 		 are probably compiling an ACVC test, but it will cause the
> > 		 code below to malfunction if we don't handle it specially.  */
> > 	      if (TREE_CODE (gnu_base_min) == INTEGER_CST
> > 		  && TREE_CODE (gnu_base_max) == INTEGER_CST
> > 		  && !TREE_OVERFLOW (gnu_base_min)
> > 		  && !TREE_OVERFLOW (gnu_base_max)
> > 		  && tree_int_cst_lt (gnu_base_max, gnu_base_min))
> > 		gnu_high = size_zero_node, gnu_min = size_one_node;
> > 
> > which now triggers on the attached testcase, whereas it used not to.
> 
> Ah, right.
> 
> I guess we do have to have TREE_OVERFLOW on sizetypes for that purpose.
> 
> I must say, then, that I missed the whole point of this change.  If
> it's just for constants, why have special handling for TREE_OVEFLOW?
> If we KNOW the constant overflows, why not say so?  What happens at run time
> has nothing to do with this.

The whole point of this excercise was to not set TREE_OVERFLOW for
the offset constant in the POINTER_PLUS_EXPR that is built for

int f(char *device)
{
  return device == ((char *)0 + ~0UL);
}

because we warn then from the C frontend:

#2  0x000000000044fd5f in parser_build_binary_op (code=PLUS_EXPR, arg1=
      {value = 0x2ad17856d5a0, original_code = ERROR_MARK}, arg2=
      {value = 0x2ad177bd1b40, original_code = ERROR_MARK})
    at /space/rguenther/src/svn/trunk/gcc/c-typeck.c:2785
2782      if (TREE_OVERFLOW_P (result.value) 
2783          && !TREE_OVERFLOW_P (arg1.value) 
2784          && !TREE_OVERFLOW_P (arg2.value))
2785        overflow_warning (result.value);

and of course (sizetype)~0UL did _not_ have overflow.  The value just
got sign-extended but fit_double_type detects overflow if _any_ change
is made.

So, conversion to sizetype bogusly sets TREE_OVERFLOW.  I can even more
constrain the fix to only ignore overflow if also the signedness
of both types match.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]