[Bug target/113994] Probable C++ code generation bug with -O2 on s390x platform

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

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |krebbel at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Reproduced on the trunk as well.  So, we have before cse1:
(insn 28 27 29 6 (set (reg:CCU 33 %cc)
        (compare:CCU (reg/v:DI 61 [ end ])
            (reg:DI 63 [ _15 ]))) "pr113994.C":13:32 discrim 7 1436
{*cmpdi_ccu}
     (nil))
(jump_insn 29 28 30 6 (set (pc)
        (if_then_else (geu (reg:CCU 33 %cc)
                (const_int 0 [0]))
            (label_ref 39)
            (pc))) "pr113994.C":13:32 discrim 7 2149 {*cjump_64}
     (int_list:REG_BR_PROB 536870916 (nil))
 -> 39)
;;  succ:       7 [50.0% (guessed)]  count:536870912 (estimated locally, freq
3.0000) (FALLTHRU)
;;              8 [50.0% (guessed)]  count:536870912 (estimated locally, freq
3.0000)
...
;; basic block 8, loop depth 0, count 536870912 (estimated locally, freq
3.0000), maybe hot
;;  prev block 7, next block 9, flags: (RTL, MODIFIED)
;;  pred:       6 [50.0% (guessed)]  count:536870912 (estimated locally, freq
3.0000)
;; bb 8 artificial_defs: { }
;; bb 8 artificial_uses: { u-1(11){ }u-1(15){ }u-1(32){ }u-1(34){ }}
(code_label 39 35 40 8 19 (nil) [1 uses])
(note 40 39 41 8 [bb 8] NOTE_INSN_BASIC_BLOCK)
(insn 41 40 42 8 (set (reg:CCU 33 %cc)
        (compare:CCU (reg/v:DI 61 [ end ])
            (reg:DI 63 [ _15 ])))
"/usr/include/c++/13/bits/basic_string.h":388:2 discrim 1 1436 {*cmpdi_ccu}
     (nil))
(jump_insn 42 41 43 8 (set (pc)
        (if_then_else (leu (reg:CCU 33 %cc)
                (const_int 0 [0]))
            (label_ref 53)
            (pc))) "/usr/include/c++/13/bits/basic_string.h":388:2 discrim 1
2149 {*cjump_64}
     (int_list:REG_BR_PROB 1073028868 (nil))
 -> 53)

Next cse1 decides that the insn 41 is redundant, because insn 28 performed the
same comparison, dominates insn 41 and %cc has not been modified.  REG_DEAD
note remains
on jump_insn 35, cse/gcse/postreload-cse doesn't remove REG_DEAD/REG_UNUSED
notes it invalidates.
ce1 pass then recomputes the notes and drops it, so fortunately this doesn't
seem to be about these notes.
%cc is even mentioned in
;; lr  out       11 [%r11] 15 [%r15] 32 [%ap] 33 [%cc] 34 [%fp] 61 63 82 84
;; live  out     11 [%r11] 15 [%r15] 32 [%ap] 33 [%cc] 34 [%fp] 61 63 82 84
after the jump_insn 29 (that actually already shows up that way in fwprop1, the
first time some pass did df_analyze after cse1).
But then something goes wrong during loop_invariant pass, jump_insn 29 above
gets (incorrect) REG_DEAD %cc note again and 33 [%cc] is dropped from lr
out/live out.
Sure, %cc is unused on one of the two successors, but on the other one is used.
And then comes loop_doloop and replaces that jump_insn 29 with
(jump_insn 226 28 225 6 (parallel [
            (set (pc)
                (if_then_else (ne (reg:DI 120)
                        (const_int 1 [0x1]))
                    (label_ref 225)
                    (pc)))
            (set (reg:DI 120)
                (plus:DI (reg:DI 120)
                    (const_int -1 [0xffffffffffffffff])))
            (clobber (scratch:DI))
            (clobber (reg:CC 33 %cc))
        ]) "pr113994.C":13:32 discrim 7 -1
     (int_list:REG_BR_PROB 536870916 (nil))
 -> 225)
(unsure whether because of the bogus REG_DEAD note, wrong df live out or
something else).  And then the cprop3 pass just removes the dead
(insn 28 27 226 8 (set (reg:CCU 33 %cc)
        (compare:CCU (reg/v:DI 61 [ end ])
            (reg:DI 63 [ _15 ]))) "pr113994.C":13:32 discrim 7 1436
{*cmpdi_ccu}
     (expr_list:REG_DEAD (reg:DI 63 [ _15 ])
        (nil)))
comparison because nothing really consumes %cc it sets (there is a user in
jump_insn 42, but there is jump_insn 226 in between which clobbers it).
And the above brctg then clobbers %cc and so we end up with
        brctg   %r10,.L40
.L19:
        jh      .L55
in the assembly.  If .L19 is reached from
        jhe     .L19
then it works fine, but if it is reached from falling through from brctg, %cc
is not what the code expects to (comparison of end with size()).