[Bug debug/103838] [11 Regression] '-fcompare-debug' failure (length) w/ -O2 --param max-early-inliner-iterations=0 --param max-inline-insns-auto=2

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

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

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

https://gcc.gnu.org/g:2712f1249e0a8dd663a02bdf710a455fe5b14e3f

commit r11-9491-g2712f1249e0a8dd663a02bdf710a455fe5b14e3f
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Dec 28 17:39:23 2021 +0100

    optabs: Fix up checking for CALLs in newly added code by double-word divmod
[PR103838]

    These two spots are meant to punt if the newly added code contains
    any CALL_INSNs, because in that case having a large sequence of insns
    that also calls something is undesirable, better have one call that
    is optimized in itself well.
    The functions do last = get_last_insn (); before emitting any insns
    (and expand_binop as the ultimate caller uses delete_insns_since if
    the expansion fails), but the checks were incorrect for 2 reasons:
    1) it checked not just what follows after that last insn, but also
       the last insn itself; so, if the division or modulo is immediately
       preceded by a CALL_INSN, then we punt; this also causes -fcompare-debug
       failures if the CALL_INSN is with -g followed by one or more DEBUG_INSNs
    2) if get_last_insn () is NULL (i.e. emitting into a new sequence), then
       we didn't check anything

    2021-12-28  Jakub Jelinek  <jakub@redhat.com>

            PR debug/103838
            * optabs.c (expand_doubleword_mod, expand_doubleword_divmod): Only
            check newly added insns for CALL_P, not the last insn of previous
            code.

            * gcc.dg/pr103838.c: New test.

    (cherry picked from commit 78ee8381bf0ebd09a92936bdb9e1b5c9fc85ad88)