| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Closes #12776
|
|
... at least enough to pass all the current tests.
|
|
Closes 12680
|
|
|
|
|
|
Pointers to zero-bit types are not zero-bit types so the function should
return something.
Closes #12716
|
|
Closes #12704
|
|
This is problematic because in practice it depends on whether the
compiler backend supports it too, as evidenced by the TODO comment about
LLVM not supporting some architectures that in fact do support tail
calls.
Instead this logic is organized strategically in src/target.zig, part of
the internal compiler source code, and the behavior tests in question
duplicate some logic for deciding whether to proceed with the test.
The proper place to expose this flag is in `@import("builtin")` - the
generated source file - so that third party compilers can advertise
whether they support tail calls.
|
|
Closes #12656
|
|
Closes #4301
Closes #5692
Closes #6281
Closes #10786
Closes #11149
Closes #11776
|
|
Previously, when lowering AIR instructions `wrap_errunion_payload`,
`wrap_errunion_err`, and `wrap_optional`, the LLVM backend would create
an alloca instruction to store the result, but did not set the alignment
on it. This caused UB which went undetected for a long time until we
started enabling the stack protector.
Closes #12594
Unblocks #12508
Inspires #12634
Tests passed locally:
* test-behavior
* test-cases
|
|
Previously, Zig had inconsistent semantics for an enum like this:
`enum(u8){zero = 0}`
Although in theory this can only hold one possible value, the tag
`zero`, Zig no longer will treat the type this way. It will do loads and
stores, as if the type has runtime bits.
Closes #12619
Tests passed locally:
* test-behavior
* test-cases
|
|
closes #12500
|
|
Closes #12572
|
|
Closes #12543
|
|
This was present in stage1 but missing from self-hosted.
|
|
This is one of the final remaining TODOs for the LLVM backend.
|
|
|
|
There still more instances of this check being tripped during behavior
tests that we need to fix before we can enable this.
|
|
on x86_64 and similar targets.
|
|
|
|
|
|
|
|
|
|
Now the backing integer of a packed struct type may be explicitly
specified with e.g. `packed struct(u32) { ... }`.
|
|
|
|
|
|
Removed the copy of param_names inside of Fn and changed to
implementation of getParamName to fetch to parameter name from the ZIR.
The signature of getParamName was also changed to take an additional
*Module argument.
|
|
This change provides a basic implementation of #2349 for stage2. There's
still quite a lot of work before this logic is as complete as what's in
Clang (https://github.com/llvm/llvm-project/blob/b3645353041818f61e2580635409ddb81ff5a272/clang/lib/CodeGen/CGStmt.cpp#L2304-L2795),
particularly considering the diversity of constraints across targets.
It's probably not worth doing the complete work until there's a clearer
picture for constraints in Zig's future dedicated ASM syntax, but at
least this gives us a small improvement for now.
As a bonus, this also fixes a bug with how we were handling `_`
identifiers.
|
|
|
|
|
|
|
|
|
|
When lowering the return type for Wasm if the calling convention is `C`,
it now correctly lower it according to what clang does as specified in:
https://github.com/WebAssembly/tool-conventions/blob/main/BasicCABI.md
This makes use of the same logic as the Wasm backend, ensuring the
generated code does not diverge in function signatures.
When passing arguments accross the C-ABI for the Wasm target,
we want slightly different behavior than x86_64.
For instance: a struct with multiple fields must always be passed
by reference, even if its ABI size fits in a single integer.
However, we do pass larger integers such as 128bit by value,
which LLVM will correctly lower to use double arguments instead.
|
|
when deciding whether to lower to x86_fp80 instructions, or softfloat
instructions.
Closes #10847
Closes #12090
|
|
|
|
|
|
|
|
Sema: fix loading and storing of optional pointers represented as pointers
|
|
|
|
When lowering a struct type to an LLVM struct type, keep track of
whether there are any underaligned fields. If so, then make it a packed
llvm struct. This works because we already insert manual padding bytes
regardless.
We could unconditionally use an LLVM packed struct; the reason we bother
checking for underaligned fields is that it is a conservative choice, in
case LLVM handles packed structs less optimally. A future improvement
could simplify this code by unconditionally using packed LLVM structs
and then make sure measure perf is unaffected.
closes #12190
|
|
|
|
This branch originally started out as a potential workaround to
address #11450. It did not solve that problem, however, it did end
up fixing #11498!
|
|
Same reasoning as previous commit.
|
|
Same reasoning as previous commit.
|
|
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
|
|
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.
|
|
There are many more instances of this check being tripped that we need
to fix before we can enable this.
|
|
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.
|
