[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:7c6cd9c05efca29a1a9635b81c86cbad25bbdbbe

commit r13-4081-g7c6cd9c05efca29a1a9635b81c86cbad25bbdbbe
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Nov 16 07:30:07 2022 +0100

    ragen-op-float: Fix up float_binary_op_range_finish [PR107668]

    The following testcase ICEs, because when !HONOR_NANS but
    HONOR_SIGNED_ZEROS, if we see
    lhs = op1 * op2;
    and know that lhs is [-0.0, 0.0] and op2 is [0.0, 0.0], the
    division of these two yields UNDEFINED and clear_nan () on it
    fails an assert.  With HONOR_NANS it would actually result in
    a known NAN, but when NANs aren't honored, we clear the NAN bits.
    Now, for the above case we actually don't know anything about
    the op1 range (except that it isn't a NAN/INF because of
    !HONOR_NANS !HONOR_INFINITIES), so I think the best is just
    to return VARYING for the case we get UNDEFINED as well.

    If we want, the op[12]_range methods perhaps can handle the
    corner cases earlier separately, say for
    lhs [0.0, 0.0] and op2 [0.0, 0.0] when HONOR_SIGNED_ZEROS this
    would be just [0.0, MAX].

    2022-11-16  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/107668
            * range-op-float.cc (float_binary_op_range_finish): Set VARYING
            also when r is UNDEFINED.

            * gcc.dg/ubsan/pr107668.c: New test.