Riscv32 clang port

[francisco-merino-quintauris]

PR checklist

• Updated function header with a short description and version number
• Added test case for bug fix or new feature
• Validated on real hardware

[jserv]

Recently, the GNU toolchain port for RISC-V 32-bit landed, with #490 and #492 merged. Given that Clang generally aims for GNU compatibility, I am wondering whether it is still necessary to maintain a separate Clang port for the RISC-V 32-bit architecture.

Would it be possible instead to standardize on the directory ports/risc-v32/gnu and introduce Clang-specific adjustments within the existing files, rather than maintaining a parallel port?

[fdesbiens]

@jserv All those contributions have been made independently by third parties.

As a first step, I was planning to merge this as is. Then, I would work with the core team to refactor things if possible. The goal is to accept the contributions and then investigate whether Clang's compatibility is good enough to avoid a distinct port.

@akifejaz, @cypherbridge and @billlamiework: feel free to chime in.

[francisco-merino-quintauris]

@fdesbiens @jserv That is a valid and good question.

The major difference between the two ports are the CMake files. There are two new files: cmake/riscv32-clang-unknown-elf.cmake and ‎cmake/riscv32_clang.cmake. Should we unify these file with the gnu cmake files and use a flag when invoking cmake to select the compiler (gnu or clang)?

As far as I can see there are another two minor differences between the gnu and the clang port/example:

• File example_build/qemu_virt/tx_initialize_low_level.S:

I needed to comment out the following line in this file as clang reports a warning.

// .global _tx_initialize_low_level

I guess I could use a #ifndef clang to avoid this warning and keep the same code.

• File example_build/qemu_virt/board.c:

I needed to remove the const qualifier in the following line as clang was reporting a warning:

void *memset(const void *des, int c,size_t n)

I am not sure why the gnu port has a const. From my point of view clang is right to throw a warning.