https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501
--- Comment #11 from prathamesh3492 at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #10) > Comment on attachment 40136 [details] > move ptrdiff_type_node initialization to build_common_tree_nodes > > So, what do you want to do for VRP in the vms case where size_t is unsigned > int (32-bit) and ptrdiff_t is long long int (64-bit)? Shall we use VARYING > range in that case, or 0 to SIZE_MAX / 2, something different? > What about the hypothetical case where size_t would be larger than ptrdiff_t? For CFN_BUILT_IN_STRLEN, we have: tree type = TREE_TYPE (gimple_call_lhs (stmt)); tree max = vrp_val_max (ptrdiff_type_node); wide_int wmax = wi::to_wide (max, TYPE_PRECISION (TREE_TYPE (max))); tree range_min = build_zero_cst (type); tree range_max = wide_int_to_tree (type, wmax - 1); If ptrdiff_t > size_t, I suppose max would be truncated to PTRDIFF_MAX / 2, Since the type of range_max is type of lhs ? In ptrdiff_t < size_t, ah it would be incorrect to use upper bound as PTRDIFF_MAX -1 since the range could be [0, SSIZE_MAX - 1] ? So instead of PTRDIFF_MAX, I guess it would be better to set range to [0, max(signed_type_for (type) - 1] which would cover both cases. Ah I see this is what you suggested in comment 4, thanks! However regardless of this bug, should we be moving ptrdiff_type_node to middle-end ? As pointed out above lto/lto-lang.c has: ptrdiff_type_node = integer_type_node, which is probably incorrect. Thanks, Prathamesh
