A significant amount of users of this project are using it for toolchain
development. These users need to ensure that their code is warning free
before submitting it upstream. Let's support this use case by adding a
configure flag '--enable-host-gcc', which does exactly that:
* build a host GCC before building other components
* setting PATH such that this new GCC is used to build the cross
toolchain
* enable -Werror for the GCC build
This patch was tested on a Fedora 39 machine (GCC 13),
with the following modification in a GCC source file:
#if __GNUC__ == 13
#error Host compiler in use!
#endif
This fails when building without the new flag and does not fail
when building with latest upstream/master (GCC 14 prerelease).
The '--enable-werror-always' was tested with a warning that showed
up recently in upstream GCC.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
pyelftools is required for a helper script.
This commit adds basic installation guide to install pyelftools and
removes "automatic installation" of pyelftools from Makefile.
This patch allows you provide the flags in build flags array acts on arch-abi
__respectively__, you can use ',' to separate them. For example:
`rv64gcv-lp64d:--param=riscv-autovec-lmul=dynamic,--param=riscv-autovec-preference=fixed-vlmax`
will be consider as two target boards same as below:
```
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-preference=fixed-vlmax
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-lmul=dynamic
```
However, you can also leverage AND(`:`), OR(`,`) operator together but the
OR(`,`) will always have the higher priority. For example:
`rv64gcv-lp64d:--param=riscv-autovec-lmul=dynamic:--param=riscv-autovec-preference=fixed-vlmax,--param=riscv-autovec-lmul=m2`
will be consider as tow target boars same as below:
```
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-lmul=dynamic/--param=riscv-autovec-preference=fixed-vlmax
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-lmul=m2
```
Signed-off-by: Pan Li <pan2.li@intel.com>
The `--with-extra-multilib-test` take the format like below for now.
"<arch>-<abi>-[code-model][;<arch>-<abi>-[code-model]*"
This patch would like to extend the sematic to support additional buil
options for each combination. Aka:
"<arch>-<abi>-[code-model][:opts]*[;<arch>-<abi>-[code-model][:opts]*]*"
opts can be one or more build options splited by ':'. For example as
below:
* --param=riscv-autovec-lmul=m1
* --param=riscv-autovec-lmul=dynamic:--param=riscv-autovec-preference=fixed-vlmax
Thus the full example of the option `--with-extra-multilib-test` will be:
`rv64gcv_zvl128b-lp64d:--param=riscv-autovec-lmul=m1;rv64gcv_zvl256b-lp64d:-
-param=riscv-autovec-lmul=dynamic:--param=riscv-autovec-preference=fixed-vlmax`
Signed-off-by: Pan Li <pan2.li@intel.com>
NOTE: This is toolchain developer facing feature.
This allow user to add extra testing multi-lib arch, it's useful when
develop and/or testing new extensions.
Usage:
--with-extra-multilib-test="arch-abi[;arch-abi]"
e.g.
linux enable enabled multilib, so default will build with follwoing
configuration:
lib32/ilp32;@march=rv32imac@mabi=ilp32
lib32/ilp32d;@march=rv32imafdc@mabi=ilp32d
lib64/lp64;@march=rv64imac@mabi=lp64
lib64/lp64d;@march=rv64imafdc@mabi=lp64d
But you want to testing more on vector stuffs like rv32gcv and rv64gcv,
then you can configure with `--with-extra-multilib-test="rv32gcv-ilp32d;rv64gcv;lp64d"`
Then the testing will run rv32imac-ilp32 rv32imafdc-ilp32d
rv64imac-lp64 rv64imafdc-lp64d and rv32gcv-ilp32d;rv64gcv;lp64d!
NOTE: Extra multilib test settings still require existing
multilib has support those extra settings, e.g. you can't add
rv32imafc_zbb-ilp32f on above example since no compatible multilib has
provided.
We currently have a stale "llvm" branch, that does not build.
However, there is clear demand in the RISC-V toolchain community
for a working LLVM on top of a recent GNU toolchain.
In order to build such a toolchain, quite some LLVM and clang know-how is
required to avoid path issues at LLVM build time or later when using clang.
The main purpose of this commit is to demonstrate a way to combine
the RISC-V GNU toolchain repo with LLVM, with the intent to save
others hours of frustration, debugging time or support time.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
There is no way to pass extra flags to gcc though
riscv-gnu-toolchain Makefile.
This is neccesary for me, because I has to rewrite gmp,
isl, mpfr, mpc folders in source of gcc project. Moreover,
I don't want to rebuild them with gcc.
Also I think, the opportunity to pass extra flags will be
convenient for many development purposes.
This patch contains three minor updates:
1. Added texinfo to OS X dependency package
2. Brew tap discoteq/discoteq is no longer required to install the flock
3. Added tip in "Installation (Newlib)" to keep similar to the description
in "Installation (Linux)" and fixed a typo.
Signed-off-by: Mingzheng Xing <xingmingzheng@iscas.ac.cn>
Let's document how to use the environment variable RUNTESTFLAGS
for selecting the tests that should be executed.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Let's document how to run all the test suites in order to increase the
number of people that will execute the tests.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
The upstream musl libc does not support 32bit RISC-V builds.
We therefore only allow building the 64bit version (i.e.,
riscv64-unknown-linux-musl-).
Signed-off-by: Florian Hofhammer <florian.hofhammer@fhofhammer.de>
This patch introduces a configure-time source-dir override for QEMU
similar to the existing overrides for the other toolchain sources.
Signed-off-by: Christoph Muellner <cmuellner@linux.com>
The current README.md only explains how to use multilib on the Linux cross-compiler, but not on the Newlib one. This might create confusion as seen here https://github.com/riscv/riscv-tools/issues/287, or makes it seem like you can't multilib on Newlib. It's also the case that the multilib option is more common on embedded toolchains rather than on Linux, so I believe this small change on documentation should clear things up.