riscv64: Bus error on qemu when executing `atomic_cas.i64`

[akldc]

.clif Test Case

test optimize    
    set opt_level=none
    set preserve_frame_pointers=true
    set enable_multi_ret_implicit_sret=true
            

function u1:1() ->  i64 fast {
    ss1 = explicit_slot 32
    const0 = 0x138570c7f69308b3f282b35c6e347036

block0:
    v8 = iconst.i64 -2844296266602371941   
    stack_store v8, ss1
    stack_store v8, ss1+8  
    stack_store v8, ss1+16 
    stack_store v8, ss1+24
    v27 = stack_addr.i64 ss1+5
    v28 = atomic_cas.i64 v27, v8, v8
    return v28
}

; print: %main()

Versions and Environment

Target Architecture: riscv64
Environment: qemu-riscv64 to emulate execution on an x86 machine.

Results

When executing this test case, qemu crashes with a bus error and returns exit code -7.

[bjorn3]

atomic_cas is implemented using lr/sc, which require the argument to be aligned to the size of the value that is being swapped, so in your case it has to be 8 bytes aligned. stack_addr.i64 ss1+5 is only 1 byte aligned however, so you get a trap.

[akldc]

@bjorn3
Thanks for the explanation.
I've found another case with unaligned access, but instead of trapping, it runs normally — though the result differs from other architectures.

test optimize    
    set opt_level=none
    set preserve_frame_pointers=true
    set enable_multi_ret_implicit_sret=true
            

function %main() -> i64,i16 fast {

    ss0 = explicit_slot 32
    const0 = 0xddbdc3ce969edd942a5e015b5cc8e67d

block0:
    v3 = iconst.i16 -19180  
    v5 = iconst.i64 0x4022_9130_1451_b514
    stack_store v5, ss0  
    stack_store v5, ss0+8  
    stack_store v5, ss0+16  
    stack_store v5, ss0+24  
    v15 = stack_addr.i64 ss0+3
    v16 = load.i64 v15
    v17 = atomic_cas.i16 v15, v3, v3 
    return v16,v17
}

; print: %main()

[x86    ] %main() -> [5887634353547194388, 12308]
[aarch64] %main() -> [5887634353547194388, 12308]
[riscv64] %main() -> [5887634353547194388, 20]

[alexcrichton]

I believe this is generally expected behavior where it's effectively UB to do atomics with unaligned addresses. In the i64 case the native instructions generate a fault, and in the i16 case the polyfill for what the platform doesn't support doesn't work correctly. Given that I believe this is all expected behavior, so I'm going to close this.