https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84811
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
CC| |rsandifo at gcc dot gnu.org
Assignee|jakub at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It is UB in the compiler, sure.
And I believe the bug is in known_subrange_p and similar patterns,
template<typename T1, typename T2, typename T3, typename T4>
inline bool
known_subrange_p (const T1 &pos1, const T2 &size1,
const T3 &pos2, const T4 &size2)
{
typedef typename poly_int_traits<T2>::coeff_type C2;
typedef POLY_BINARY_COEFF (T2, T4) size_diff_type;
typedef poly_span_traits<T1, T3, size_diff_type> span;
return (known_gt (size1, POLY_INT_TYPE (T2) (0))
&& (poly_coeff_traits<C2>::signedness > 0
|| known_size_p (size1))
&& known_size_p (size2)
&& known_ge (pos1, pos2)
&& known_le (size1, size2)
&& known_le (span::cast (pos1 - pos2), size2 - size1));
}
isn't enough if pos2 is negative (i.e. poly_coeff_traits<C3>::signedness > 0),
we can run into overflow that way.
The standard way to handle this pos1 - pos2 <= size2 - size1 is perform the
computation in unsigned type, but poly-int.h probably doesn't have so far an
easy way to cast to corresponding unsigned poly_int if signedness > 0.
What complicates it even more is that pos1 and pos2 can have different types.
size2 - size1 could in theory overflow too, even assuming that sizeN can be
only positive or -1, if size1 is -1 and size2 maximum signed size, but perhaps
we can't run into that.
I think other poly-int.h templates suffer from similar issues.
Richard, can you please handle this?
