Re: [PATCH v2] RISC-V: zicond: Fix opt2 pattern

[Tsukasa OI <research_trasio@irq.a4lg.com>]

Sorry, I want to directly reply to Jeff but I couldn't because I haven't
subscribed to gcc-patches and Jeff's recent reply hasn't archived yet.

Bug confirmed for me.

I tried the full test with following configuration (I found another bug
[ICE] as I submitted a quick fix while testing this and requires
following patch set to be applied; will make a PATCH v2 though):
<https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629175.html>

Possibly, ICE, simulator configuration and/or dirty build tree might be
the reason Jeff couldn't reproduce the bug.

# ZiCond enabled
# Remove "_zicond" to disable ZiCond.
# ${SYSROOT} points to the prebuilt sysroot with
# glibc + libgcc with -march=rv64imafdc -mabi=lp64d
${GCC_SRCDIR}/configure \
    --target=riscv64-unknown-linux-gnu \
    --prefix=${PREFIX}               \
    --with-sysroot=${SYSROOT}        \
    --with-system-zlib               \
    --disable-shared                 \
    --enable-tls                     \
    --enable-languages=c,c++         \
    --disable-libmudflap             \
    --disable-libssp                 \
    --disable-libquadmath            \
    --disable-libsanitizer           \
    --disable-nls                    \
    --disable-bootstrap              \
    --disable-multilib               \
    --with-tune=rocket               \
    --with-arch=rv64imafdc_zicond    \
    --with-abi=lp64d                 \
    --with-isa-spec=20191213

Then I ran "make; make check RUNTESTFLAGS='--target_board=riscv-sim'".
Note that I configured DejaGnu (riscv-sim.exp) to execute tests with:
"qemu-riscv64 -L ${SYSROOT} -cpu rv64,g=on,x-zicond=on" (QEMU 8.1.0
Linux user emulation).

Warning: abort() on QEMU with Linux user emulation causes QEMU to abort,
too (possibly making many coredumps).

The diff of test failures are as follows.
-: Occurs only when ZiCond is disabled
+: Occurs only when ZiCond is enabled

-FAIL: 30_threads/async/async.cc execution test
+FAIL: gcc.c-torture/execute/pr60003.c   -O1  execution test
+FAIL: gcc.dg/setjmp-3.c execution test
+FAIL: gcc.dg/torture/stackalign/setjmp-3.c   -O1  execution test
+FAIL: gcc.dg/torture/stackalign/setjmp-3.c   -O1 -fpic execution test

I'm not sure why 30_threads/async/async.cc succeeds after enabling the
'Zicond' extension but I am sure that setjmp-3.c failures are caused by
this very bug.

Smaller example (not involving setjmp / longjmp) to reproduce this bug
in my environment is as follows (you *don't* have to apply my patch
above, make all-gcc && make install-gcc overwriting existing RV64 GCC
prefix will work):

> #include <stdio.h>
> 
> __attribute__((noinline, noclone))
> void sample(long* a)
> {
>     *a = 1;
> }
> 
> __attribute__((noinline, noclone))
> long foo(long x)
> {
>     long a = 0;
>     sample(&a); // a is overwritten to 1.
>     if (a == 0)
>         return 0;
>     else
>         return x; // should be always taken
> }
> 
> int main(int argc, char** argv)
> {
>     printf("%ld\n", foo(5)); // should print 5
>     return 0;
> }

Note that we have to make sure that variables are not easily inferred by
another optimization pass (that's why I needed two functions).

> riscv64-unknown-linux-gnu-gcc -march=rv64gc_zicond -O1 -static a.c
> qemu-riscv64 -cpu rv64,g=on,x-zicond=on ./a.out

printed 0, not 5 as I expected.

I support Vineet's patch set (v2).

Thanks,
Tsukasa