Codegen error with upstream gcc

[cliffordwolf]

Sorry for dropping a not completely debugged issue here, but I have to context switch to another task and I wanted to post what I have found so far so other may take over.

I'm building riscv-pk with upstream gcc ("trunk" from git://gcc.gnu.org/git/gcc.git). In gcc commit 98125d0d3 they enabled the tree-loop-distribute-patterns optimizer in -O2, which breaks pk for me.

With tree-loop-distribute-patterns:

+ /opt/riscv64b/bin/spike pk riscv-isa-sim-demo
bbl loader
terminate called after throwing an instance of 'std::runtime_error'
  what():  bad syscall #90463429510455458

And without tree-loop-distribute-patterns:

+ /opt/riscv64b/bin/spike pk riscv-isa-sim-demo
bbl loader
Hello World!

Adding the following pragmas to riscv-pk/util/string.c fixes the issue for me.

#pragma GCC push_options
#pragma GCC optimize ("no-tree-loop-distribute-patterns")
void* memset(void* dest, int byte, size_t len)
{
  if ((((uintptr_t)dest | len) & (sizeof(uintptr_t)-1)) == 0) {
    uintptr_t word = byte & 0xFF;
    word |= word << 8;
    word |= word << 16;
    word |= word << 16 << 16;

    uintptr_t *d = dest;
    while (d < (uintptr_t*)(dest + len))
      *d++ = word;
  } else {
    char *d = dest;
    while (d < (char*)(dest + len))
      *d++ = byte;
  }
  return dest;
}
#pragma GCC pop_options

Probably all that's missing now is staring at this code for a while to figure out what unintended UB the compiler exploits here, but I'm out of time for now..

[aswaterman]

Seems like you already did 90% of the work, thanks :)... I'll take it from here.

[aswaterman]

-ftree-loop-distribute-patterns enables pattern-matching the memset body into a call to memset, making it recurse forever. Disabling that option when compiling memset is exactly what glibc does.

[aswaterman]

Should be fixed; thanks again for narrowing it down.

[rgdaddio]

FWIW This issue still exists in: github.com/riscv-software-src/riscv-tools version.

[pavitrar20]

I am still encountering the same problem as described here -

I need to test some simple vector instructions so using rvv-next branch
riscv-gnu-toolchain$ git submodule status
9826b03b747b841f5fc6de2054bf1ef3f5c4bdf3 glibc (glibc-2.33)
-85e0e3519655220688e757b9d5bfd314923548bd musl
415fdd4279b85eeec9d54775ce13c5c412451e08 newlib (newlib-4.1.0)
-553032db17440f8de011390e5a1cfddd13751b0b qemu
b51c2fec1da205ea3e7354cbb3e253018d64873c riscv-binutils (binutils-2_39)
-4ea498a8e1fafeb568530d84db1880066478c86b riscv-dejagnu
+eb96155f49deefcde0b054f6c02aa67c607ac482 riscv-gcc (remotes/origin/riscv-gcc-rvv-next)
5da071ef0965b8054310d8dde9975037b0467311 riscv-gdb (remotes/origin/fsf-gdb-10.1-with-sim)

[rgdaddio]

I am still encountering the same problem as described here -

I need to test some simple vector instructions so using rvv-next branch riscv-gnu-toolchain$ git submodule status 9826b03b747b841f5fc6de2054bf1ef3f5c4bdf3 glibc (glibc-2.33) -85e0e3519655220688e757b9d5bfd314923548bd musl 415fdd4279b85eeec9d54775ce13c5c412451e08 newlib (newlib-4.1.0) -553032db17440f8de011390e5a1cfddd13751b0b qemu b51c2fec1da205ea3e7354cbb3e253018d64873c riscv-binutils (binutils-2_39) -4ea498a8e1fafeb568530d84db1880066478c86b riscv-dejagnu +eb96155f49deefcde0b054f6c02aa67c607ac482 riscv-gcc (remotes/origin/riscv-gcc-rvv-next) 5da071ef0965b8054310d8dde9975037b0467311 riscv-gdb (remotes/origin/fsf-gdb-10.1-with-sim)

If you are encountering the error described earlier in this chain you should be able to directly apply the changes posted by @cliffordwolf above to riscv-pk/util/string.c and it should fix it (it worked for me at least). Or find a more updated version that includes the changes (if it is the same problem). HTH