On 10/15/19 2:16 PM, Jakub Jelinek wrote:
On Tue, Oct 15, 2019 at 08:35:07AM -0400, Aldy Hernandez wrote:
I'm seeing this on 32-bit i386-pc-solaris2.11 and sparc-sun-solaris2.11,
with more reports for armv8l, pru, and s390x.
Comparing the dumps between 64 and 32-bit, I see
-_1: int * [1B, -1B]
+_1: int * [1B, 4294967295B]
I wonder why 32-bit targets at displaying 4294967295 instead of -1. Or are
pointers 64-bits here?
Because the dump method does:
if (INTEGRAL_TYPE_P (ttype)
&& vrp_val_is_max (max ())
&& TYPE_PRECISION (ttype) != 1)
fprintf (file, "+INF");
else
print_generic_expr (file, max ());
so for integral types and maximum value, it prints +INF, but not for
pointers.
Ah, I see.
Perhaps we want to print +INF also for pointers,
if ((INTEGRAL_TYPE_P (ttype) || POINTER_TYPE_P (ttype))
&& vrp_val_is_max (max (), true)
&& TYPE_PRECISION (ttype) != 1)
fprintf (file, "+INF");
else
print_generic_expr (file, max ());
That sounds reasonable, though I would use supports_type_p() instead of
open-coding the check for INTEGRAL and POINTER.
Would you take care of this, or shall I?
but maybe vrp_val_is_{min,max} should be rewritten for pointer types to be
more efficient, don't create trees, for min just use integer_zerop and for
max just compare wide_int?
That sounds like a separate issue, but sure. No complaints.
Note, that I highly dislike the whole handle_pointers=bool argument in
vrp_*val*, even though I added it. I think it should default to the
handle_pointers behavior, though I was unsure what would break, so I
kept existing behavior gated by a bool (yuck).
Thanks.
Aldy
