* Use a debug build of stage3 instead of a debug build of stage2 for
our self-hosted compiler test coverage.
* Move coverage from stage1 to stage3 for:
- building self-hosted without LLVM
- building self-hosted for 32-bit arm
- test-compiler-rt
- test-behavior
- test-std
- test-compare-output
- test-asm-link
- test-fmt
We were accidentally returning a pointer to stack memory, because these
arguments were passed by value. It's just an accident that stage 1 was
passing these by reference, so things were alright until stage 3.
This is a possible workaround for
https://github.com/llvm/llvm-project/issues/56585
On my computer it makes stage3-release go from false positive
compilation errors on the behavior tests to "segmentation fault".
Is this forwards progress or backwards progress? I have no idea.
See #11450
Since we know the offset, we may as well read starting there. Still expects
rpath to fit in 4096 bytes; that might be worth fixing in the future.
Fixes issue #12112
This is a workaround for https://github.com/llvm/llvm-project/issues/56585
which causes writes to i1 in memory to be optimized to an incorrect value.
Unfortunately, this does not save users from running into this bug with u1
in their own types.
However, this does seem to be enough to get the behavior tests working.
This resolves#11450 on my machine.
* io_uring: fix the timeout_remove test
The test does a IORING_OP_TIMEOUT followed with a IORING_OP_TIMEOUT_REMOVE
and assumed we would get the CQEs in the same order.
Linux v5.18 changed how this works and we now get them in the reverse order.
The documentation doesn't explicitly say which CQE we should get first
so just make the test work with both cases.
* io_uring: fix the remove_buffers test
The original test was buggy but accidentally worked with kernels < 5.18
The test assumed that IORING_OP_REMOVE_BUFFERS removed from the start of
but in fact the documentation doesn't specify which buffer is removed,
only that a certain number of buffers are removed.
Starting with the kernel 5.18 the check for the `used_buffer_id` fails.
Turns out that previous kernels removed buffers in such a way that the
remaining buffer for this read would always be 0, however this isn't
true anymore.
Instead of checking a specific value just check that the `used_buffer_id`
corresponds to a valid ID.
Before this would fail to compile:
```
fn testFn(alloc: std.mem.Allocator, arr: []const u8) !void {
_ = alloc;
_ = arr;
}
test "checkAll" {
var arr = [_]u8{ 1, 2, 3 };
try std.testing.checkAllAllocationFailures(std.testing.allocator, testFn, .{arr[0..]});
}
```
with the error `error: Unexpected type for extra argument at index 0: expected []const u8, found *[3]u8`
By removing this strict equality check, we allow the type checking to be done during the `@field(args, arg_i_str) = @field(extra_args, field.name);` instead, which then allows for things like type coercion to work, but still will give a compile error if the types are incorrect. So, after this change, the above succeeds (because `*[3]u8` can be coerced to `[]const u8`).
The new compile error when providing an incorrect type that can't be coerced looks like this:
```
zig/lib/std/testing.zig:639:35: error: expected type '[]const u8', found '*[3]u32'
@field(args, arg_i_str) = @field(extra_args, field.name);
^
```
This is really minor but the issue this fixes is that if you copy-paste this output of `--show-builtin` into your `build.zig` for example then the formatter will format
```
pub const os = std.Target.Os{
.tag = .freestanding,
.version_range = .{ .none = {} }
};
```
to
```
pub const os = std.Target.Os{ .tag = .freestanding, .version_range = .{ .none = {} } };
```
which doesn't match the output.
With this comma, the output will stay the way it is after a `zig fmt`.
This implementation uses the F_KINFO fcntl command added in FreeBSD
13 release. FreeBSD 12 users get a compile error.
Co-authored-by: Stephen Gregoratto <dev@sgregoratto.me>
Previously, the Zig ABI size and LLVM ABI size of these types disagreed
sometimes. This code also corrects the logging messages to not trigger
LLVM assertions.
This reverts commit 2eaef84ebe.
Here is a motivating example:
```zig
const E = union(enum) {
A: [9]u8,
B: u64,
};
```
```llvm
%test2.E = type { { i64, [1 x i8] }, i1, [6 x i8] }
```
```
error(codegen): when lowering test2.E, Zig ABI size = 16 but LLVM ABI size = 24
```
CMake has a surprising default behavior where looking up a library by
multiple names gives the name order higher priority than the directory
search order.
For example, if your system provides "llvm-config-14" and
CMAKE_PREFIX_PATH includes "llvm-config", CMake will always end up
choosing the system-provided llvm-config-14.
This change add NAMES_PER_DIR to request the more sensible behavior:
directory search order has higher priority than name order, so
CMAKE_PREFIX_PATH always wins over system-provided tools/libraries.
It did not handle properly when the dummy operand was a comptime_int; it
was crashing in coerce because comptime_int is supposed to be
comptime-known. So when calling coerceResultPtr, we pass the actual
operand, not a dummy operand, which means it will have the proper
comptime value when necessary.
Previously, the logic for analyzing coerce_result_ptr would generate
invalid bitcast instructions which did not include coercion logic, such
as optional wrapping, resulting in miscompilations.
Now, the logic of resolve_inferred_alloc goes back over all the
placeholders inserted by coerce_result_ptr, and replaces them with logic
doing the proper coercions.
Closes#12045
