[gcc r12-7386] internal-fn: Call do_pending_stack_adjust in expand_SPACESHIP [PR104679]

Jakub Jelinek jakub@gcc.gnu.org
Fri Feb 25 09:57:27 GMT 2022


https://gcc.gnu.org/g:526fbcfa636fb7e544c1ad69101dbccecbee8b28

commit r12-7386-g526fbcfa636fb7e544c1ad69101dbccecbee8b28
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Feb 25 10:56:46 2022 +0100

    internal-fn: Call do_pending_stack_adjust in expand_SPACESHIP [PR104679]
    
    The following testcase is miscompiled on ia32 at -O2, because
    when expand_SPACESHIP is called, we have pending stack adjustment
    from the foo call right before it.
    Now, ix86_expand_fp_spaceship uses emit_jump_insn several times
    but then emit_jump also several times.  While emit_jump_insn doesn't
    do do_pending_stack_adjust (), emit_jump does, so we end up with:
    ...
        8: call [`_Z3foodl'] argc:0x10
          REG_CALL_DECL `_Z3foodl'
        9: r88:DF=[`a']
       10: r89:HI=unspec[cmp(r88:DF,0.0)] 25
       11: flags:CC=unspec[r89:HI] 26
       12: pc={(unordered(flags:CCFP,0))?L27:pc}
          REG_BR_PROB 536868
       66: NOTE_INSN_BASIC_BLOCK 4
       13: pc={(uneq(flags:CCFP,0))?L19:pc}
          REG_BR_PROB 214748364
       67: NOTE_INSN_BASIC_BLOCK 5
       14: pc={(flags:CCFP>0)?L23:pc}
          REG_BR_PROB 536870916
       68: NOTE_INSN_BASIC_BLOCK 6
       15: r86:SI=0xffffffffffffffff
       16: {sp:SI=sp:SI+0x10;clobber flags:CC;}
          REG_ARGS_SIZE 0
       17: pc=L29
       18: barrier
       19: L19:
       69: NOTE_INSN_BASIC_BLOCK 7
    ...
    The sp += 16 pending stuck adjust was emitted in the middle of the
    sequence and is effective only for the single case of the 4 possibilities
    where .SPACESHIP returns -1, in all other cases the stack isn't adjusted
    and so we ICE during dwarf2cfi.
    
    Now, we could either call do_pending_stack_adjust in
    ix86_expand_fp_spaceship, or use there calls that actually don't call
    do_pending_stack_adjust (but having the stack adjustment across branches is
    generally undesirable), or we can call it in expand_SPACESHIP for all
    targets (note, just i386 currently implements it).
    I chose the generic code because e.g. expand_{addsub,neg,mul}_overflow
    in the same file also call do_pending_stack_adjust in internal-fn.cc for the
    same reasons, that it is expected that most if not all targets will expand
    those through jumps and we don't want all of the targets to need to deal
    with that.
    
    2022-02-25  Jakub Jelinek  <jakub@redhat.com>
    
            PR middle-end/104679
            * internal-fn.cc (expand_SPACESHIP): Call do_pending_stack_adjust.
    
            * g++.dg/torture/pr104679.C: New test.

Diff:
---
 gcc/internal-fn.cc                      |  2 ++
 gcc/testsuite/g++.dg/torture/pr104679.C | 22 ++++++++++++++++++++++
 2 files changed, 24 insertions(+)

diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
index 3f1fbc6c91a..dd3ee0df64b 100644
--- a/gcc/internal-fn.cc
+++ b/gcc/internal-fn.cc
@@ -4437,6 +4437,8 @@ expand_SPACESHIP (internal_fn, gcall *stmt)
   tree rhs2 = gimple_call_arg (stmt, 1);
   tree type = TREE_TYPE (rhs1);
 
+  do_pending_stack_adjust ();
+
   rtx target = expand_expr (lhs, NULL_RTX, VOIDmode, EXPAND_WRITE);
   rtx op1 = expand_normal (rhs1);
   rtx op2 = expand_normal (rhs2);
diff --git a/gcc/testsuite/g++.dg/torture/pr104679.C b/gcc/testsuite/g++.dg/torture/pr104679.C
new file mode 100644
index 00000000000..ccdfbaecd57
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/pr104679.C
@@ -0,0 +1,22 @@
+// PR middle-end/104679
+// { dg-do compile }
+
+struct A { ~A (); };
+void foo (double, long);
+void bar ();
+double a;
+long b;
+
+void
+baz ()
+{
+  foo (a, b);
+  if (a == 0.0)
+    ;
+  else
+    while (a > 0.0)
+      {
+        A c;
+        bar ();
+      }
+}


More information about the Gcc-cvs mailing list