<html>
    <head>
      <base href="https://bugs.llvm.org/">
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - RISCV stack temporary overflow"
   href="https://bugs.llvm.org/show_bug.cgi?id=49500">49500</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>RISCV stack temporary overflow
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>libraries
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>trunk
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>PC
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Linux
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>Backend: RISC-V
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>unassignedbugs@nondot.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>jistone@redhat.com
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>asb@lowrisc.org, llvm-bugs@lists.llvm.org
          </td>
        </tr></table>
      <p>
        <div>
        <pre>This is a clone of SystemZ <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - SystemZ stack temporary overflow"
   href="show_bug.cgi?id=49322">bug 49322</a> because it applies to RISCV too.
That was fixed in <a href="https://reviews.llvm.org/D97514">https://reviews.llvm.org/D97514</a>.

When a large integer argument on riscv is converted to indirect, but the type
is not a multiple of 64 bits, the writes to the stack are all still in 64-bit
chunks and may clobber neighboring values on the stack.

This can be seen on the SystemZ test added above using -mtriple=riscv64:
llvm/test/CodeGen/SystemZ/args-11.ll

RISCV doesn't have a problem with the first part calling fn1(i96), because that
argument is passed in two registers, so the stack alloca is unaffected.
However, the second part calling fn3(i136) does show the stack-clobbering bug:

declare void @fn3(i136)
define i32 @fn4() {
  %1 = alloca i32
  store i32 -1, i32* %1
  call void @fn3(i136 0)
  %2 = load i32, i32* %1
  ret i32 %2
}

        .globl  fn4                             # -- Begin function fn4
        .p2align        2
        .type   fn4,@function
fn4:                                    # @fn4
        .cfi_startproc
# %bb.0:
        addi    sp, sp, -32
        .cfi_def_cfa_offset 32
        sd      ra, 24(sp)                      # 8-byte Folded Spill
        .cfi_offset ra, -8
        addi    a0, zero, 1
        slli    a0, a0, 32
        addi    a0, a0, -1
        sw      a0, 20(sp)
        sd      zero, 16(sp)
        sd      zero, 8(sp)
        mv      a0, sp
        sd      zero, 0(sp)
        call    fn3@plt
        lw      a0, 20(sp)
        ld      ra, 24(sp)                      # 8-byte Folded Reload
        addi    sp, sp, 32
        ret
.Lfunc_end1:
        .size   fn4, .Lfunc_end1-fn4
        .cfi_endproc
                                        # -- End function

The store i32 is "sw a0, 20(sp)", immediately overwritten by "sd zero, 16(sp)".</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>