Closed thixotropist closed 4 months ago
This issue raises several design questions:
We want to include compiler suites at the workspace level with MODULE.bazel
lines like:
bazel_dep(name="gcc_riscv_suite", version="14.1.0")
bazel_dep(name="gcc_x86_64_suite", version="14.1.0")
Good Bazel practice is to avoid mixing multiple versions of an external repo in any given workspace, so we won't be mixing gcc 14.1.0 and gcc 15.x in any build. We can still support multiple different platforms and toolchains in a single workspace.
Bazel constructs like cc_toolchain_config
and the wrapper files include lots of references to the module name, version, and build target. These BUILD and wrapper files will need to be modified when switching between one compiler suite module version and another.
Does this justify a long-lived branch for each 'current' version of gcc?
bazel_compiler_modules
Commit 06806ca supports importing gcc 14.1 compiler suites for x86_64 and riscv architectures in the main branch.
The next step is to add a long-lived new branch, gcc-next
, to switch the workspace to the developmental (unreleased) gcc 15 compilers. A good test case may be comparing whisper builds with riscv vector extensions enabled at gcc 14.1 and at gcc 15.0.
GCC-15 is now enabled in the new branch gcc-next
for both RISCV and x86_64 architectures.
Add a gcc-15 toolchain tracking the tip of the gcc, binutils, and glibc repos. We're particularly interested in understanding which RISCV developers are adding support for new ISA extensions or code transformations.
At first glance, the emphasis seems to be on ML or AI extensions. Look for extensions that support concurrency controls, cache management, and networking apps.
Try to package the gcc-15 infrastructure as one or more Bazel mods, rather than leave all of the compiler suite infrastructure inside every project repo that uses the toolchain.