[Bug c++/108365] [9/10/11/12/13 Regression] Wrong code with -O0

cvs-commit at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Sat Jan 14 09:18:53 GMT 2023


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

--- Comment #7 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:5b3a88640f962d4ffca31ae651bed2d8672f1a8c

commit r13-5163-g5b3a88640f962d4ffca31ae651bed2d8672f1a8c
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Jan 14 10:17:14 2023 +0100

    c++: Avoid incorrect shortening of divisions [PR108365]

    The following testcase is miscompiled, because we shorten the division
    in a case where it should not be shortened.
    Divisions (and modulos) can be shortened if it is unsigned division/modulo,
    or if it is signed division/modulo where we can prove the dividend will
    not be the minimum signed value or divisor will not be -1, because e.g.
    on sizeof(long long)==sizeof(int)*2 && __INT_MAX__ == 0x7fffffff targets
    (-2147483647 - 1) / -1 is UB
    but
    (int) (-2147483648LL / -1LL) is not, it is -2147483648.
    The primary aim of both the C and C++ FE division/modulo shortening I
assume
    was for the implicit integral promotions of {,signed,unsigned} {char,short}
    and because at this point we have no VRP information etc., the shortening
    is done if the integral promotion is from unsigned type for the divisor
    or if the dividend is an integer constant other than -1.
    This works fine for char/short -> int promotions when char/short have
    smaller precision than int - unsigned char -> int or unsigned short -> int
    will always be a positive int, so never the most negative.

    Now, the C FE checks whether orig_op0 is TYPE_UNSIGNED where op0 is either
    the same as orig_op0 or that promoted to int, I think that works fine,
    if it isn't promoted, either the division/modulo common type will have the
    same precision as op0 but then the division/modulo is unsigned and so
    without UB, or it will be done in wider precision (e.g. because op1 has
    wider precision), but then op0 can't be minimum signed value.  Or it has
    been promoted to int, but in that case it was again from narrower type and
    so never minimum signed int.

    But the C++ FE was checking if op0 is a NOP_EXPR from TYPE_UNSIGNED.
    First of all, not sure if the operand of NOP_EXPR couldn't be non-integral
    type where TYPE_UNSIGNED wouldn't be meaningful, but more importantly,
    even if it is a cast from unsigned integral type, we only know it can't be
    minimum signed value if it is a widening cast, if it is same precision or
    narrowing cast, we know nothing.

    So, the following patch for the NOP_EXPR cases checks just in case that
    it is from integral type and more importantly checks it is a widening
    conversion, and then next to it also allows op0 to be just unsigned,
    promoted or not, as that is what the C FE will do for those cases too
    and I believe it must work - either the division/modulo common type
    will be that unsigned type, then we can shorten and don't need to worry
    about UB, or it will be some wider signed type but then it can't be most
    negative value of the wider type.
    And changes both the C and C++ FEs to do the same thing, using a helper
    function in c-family.

    2023-01-14  Jakub Jelinek  <jakub@redhat.com>

            PR c++/108365
            * c-common.h (may_shorten_divmod): New static inline function.

            * c-typeck.cc (build_binary_op): Use may_shorten_divmod for
integral
            division or modulo.

            * typeck.cc (cp_build_binary_op): Use may_shorten_divmod for
integral
            division or modulo.

            * c-c++-common/pr108365.c: New test.
            * g++.dg/opt/pr108365.C: New test.
            * g++.dg/warn/pr108365.C: New test.


More information about the Gcc-bugs mailing list