[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77899

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #3)
> The offset is this in plus_stmt_object_size() in tree-object-size.c:
> 
>  <ssa_name 0x7ffff0daa948
>     type <integer_type 0x7ffff0da41f8 sizetype public unsigned DI
>         size <integer_cst 0x7ffff0da0ca8 constant 64>
>         unit size <integer_cst 0x7ffff0da0cc0 constant 8>
>         align 64 symtab 0 alias set -1 canonical type 0x7ffff0da41f8
> precision 64 min <integer_cst 0x7ffff0da0cd8 0> max <integer_cst
> 0x7ffff0db1480 18446744073709551615>>
>     static visited
>     def_stmt _1 = (sizetype) i_3(D);
>     version 1
>     ptr-info 0x7ffff0ec8f20>
> 
> I can work around it there by checking the type of i_3(D) (which is signed
> char) and using its range to bound _1.  I wonder if this same workaround
> could be put in get_range_info until POINTER_PLUS_EXPR is changed to take a
> signed offset as you suggest.

Consumers need to interpret POINTER_PLUS_EXPR offset (and MEM_REF offset)
as signed entity.  This means you want to interpret the range as signed
as well -- there is nothing wrong with the range as recorded as Andrew notices,
it's fully correct.

-> INVALID.