GCC bug 119085, which affects versions 13.0--15.1, is being triggered by
the C backend, resulting in a (small but critical) miscompilation in
zig2. Unfortunately, we can't really work around that bug without a
command-line flag, because the bug is sensitive to things like the order
in which `struct` types are defined.
Therefore, I have added an option to `bootstrap.c` which causes it to
pass the appropriate flag to `gcc` to disable the optimization pass in
question. This flag can likely be removed in future, once the affected
GCC versions become less common.
At least one of our x86_64-linux CI machines is using an affected GCC
version, so I also updated the relevant CI script to pass this flag when
testing no-LLVM bootstrap.
CMakeLists also has a workaround, but no user intervention is required
there: the GCC version range is automatically detected by CMakeLists.
* Introduce `-Ddebug-extensions` for enabling compiler debug helpers
* Replace safety mode checks with `std.debug.runtime_safety`
* Replace debugger helper checks with `!builtin.strip_debug_info`
Sometimes, you just have to debug optimized compilers...
Part of #19063.
Primarily, this moves Aro from deps/ to lib/compiler/ so that it can be
lazily compiled from source. src/aro_translate_c.zig is moved to
lib/compiler/aro_translate_c.zig and some of Zig CLI logic moved to a
main() function there.
aro_translate_c.zig becomes the "common" import for clang-based
translate-c.
Not all of the compiler was able to be detangled from Aro, however, so
it still, for now, remains being compiled with the main compiler
sources due to the clang-based translate-c depending on it. Once
aro-based translate-c achieves feature parity with the clang-based
translate-c implementation, the clang-based one can be removed from Zig.
Aro made it unnecessarily difficult to depend on with these .def files
and all these Zig module requirements. I looked at the .def files and
made these observations:
- The canonical source is llvm .def files.
- Therefore there is an update process to sync with llvm that involves
regenerating the .def files in Aro.
- Therefore you might as well just regenerate the .zig files directly
and check those into Aro.
- Also with a small amount of tinkering, the file size on disk of these
generated .zig files can be made many times smaller, without
compromising type safety in the usage of the data.
This would make things much easier on Zig as downstream project,
particularly we could remove those pesky stubs when bootstrapping.
I have gone ahead with these changes since they unblock me and I will
have a chat with Vexu to see what he thinks.
The idea here is that the zig2 executable is perhaps the more useful
deliverable until we implement our own optimization passes. This will
allow system packages to provide Zig, and use it to compile Zig
projects, all without LLVM!
When a zig compiler without LLVM extensions is satisfactory, this
greatly simplified build-from-source process can be used.
This could be useful for users who only want to contribute to the
standard library, for example.
