| Age | Commit message (Collapse) | Author |
|---|
|
This ABI bug was fixed in LLVM 20.
|
|
LLVM is increasingly making use of this module flag when present.
|
|
|
|
Closes #21818.
|
|
|
|
The "musl" part of the Zig target triples `wasm32-wasi-musl` and
`wasm32-emscripten-musl` refers to the libc, not really the ABI.
For WASM, most LLVM-based tooling uses `wasm32-wasi`, which is
normalized into `wasm32-unknown-wasi`, with an implicit `-unknown` and
without `-musl`.
Similarly, Emscripten uses `wasm32-unknown-emscripten` without `-musl`.
By using `-unknown` instead of `-musl` we get better compatibility with
external tooling.
|
|
x86_64: rewrite wrapping multiplication
|
|
Emscripten currently implements `emscripten_return_address()` by calling
out into JavaScript and parsing a stack trace, which introduces
significant overhead that we would prefer to avoid in release builds.
This is especially problematic for allocators because the generic parts
of `std.mem.Allocator` make frequent use of `@returnAddress`, even
though very few allocator implementations even observe the return
address, which makes allocators nigh unusable for performance-critical
applications like games if the compiler is unable to devirtualize the
allocator calls.
|
|
|
|
Too many bugs have been found with `truncate` at this point, so it was
rewritten from scratch.
Based on the doc comment, the utility of `convertToTwosComplement` over
`r.truncate(a, .unsigned, bit_count)` is unclear and it has a subtle
behavior difference that is almost certainly a bug, so it was deleted.
|
|
|
|
Closes #22517.
|
|
|
|
Resolves #23212
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x86_64: rewrite aggregate init
|
|
This should be a lot easier to maintain. It's also a small step towards
eventually making the builder API parse the data layout string in order to
answer layout questions that we need to ask during code generation.
|
|
|
|
|
|
|
|
This deep hash map doesn't work
|
|
Co-authored-by: Robin Voetter <robin@voetter.nl>
|
|
|
|
compiler: Implement `@disableIntrinsics()` builtin function.
|
|
It appears to just be a 1:1 copy of riscv64, including the super weird sign
extension quirk for u32.
Contributes to #21671.
|
|
|
|
Closes #21833.
Closes #22110.
|
|
|
|
`llvm`: Use inline variants of `memcpy`/`memset` intrinsics when using `-fno-builtin`
|
|
This is a correctness issue: When -fno-builtin is used, we must assume that we
could be compiling the memcpy/memset implementations, so generating calls to
them is problematic.
|
|
|
|
- allow `-fsanitize-coverage-trace-pc-guard` to be used on its own without enabling the fuzzer.
(note that previouly, while the flag was only active when fuzzing, the fuzzer itself doesn't use it, and the code will not link as is.)
- add stub functions in the fuzzer to link with instrumented C code (previously fuzzed tests failed to link if they were calling into C):
while the zig compile unit uses a custom `EmitOptions.Coverage` with features disabled,
the C code is built calling into the clang driver with "-fsanitize=fuzzer-no-link" that automatically enables the default features.
(see https://github.com/llvm/llvm-project/blob/de06978ebcff5f75913067b019d2d522d0be0872/clang/lib/Driver/SanitizerArgs.cpp#L587)
- emit `-fsanitize-coverage=trace-pc-guard` instead of `-Xclang -fsanitize-coverage-trace-pc-guard` so that edge coverrage is enabled by clang driver. (previously, it was enabled only because the fuzzer was)
|
|
|
|
`OpCapability` and `OpExtension` now can also be emitted from inline assembly
|
|
|
|
|
|
Functions like isMinGW() and isGnuLibC() have a good reason to exist: They look
at multiple components of the target. But functions like isWasm(), isDarwin(),
isGnu(), etc only exist to save 4-8 characters. I don't think this is a good
enough reason to keep them, especially given that:
* It's not immediately obvious to a reader whether target.isDarwin() means the
same thing as target.os.tag.isDarwin() precisely because isMinGW() and similar
functions *do* look at multiple components.
* It's not clear where we would draw the line. The logical conclusion before
this commit would be to also wrap Arch.isX86(), Os.Tag.isSolarish(),
Abi.isOpenHarmony(), etc... this obviously quickly gets out of hand.
* It's nice to just have a single correct way of doing something.
|
|
|
|
|
|
* arm_apcs is the long dead "OABI" which we never had working support for.
* arm_aapcs16_vfp is for arm-watchos-none which is a dead target that we've
dropped support for.
|
|
|
|
This was for a hobby project that appears to be dormant for now. This can be
added back if the project is resumed in the future.
|
|
Can't imagine this working, but might as well try until I remember why.
Closes #21439
|
|
Closes #19905
|
|
Closes #21490
|
