| Age | Commit message (Collapse) | Author |
|
Closes #18723
|
|
|
|
|
|
|
|
|
|
This reverts commit 6f0198cadbe29294f2bf3153a27beebd64377566.
|
|
This reverts commit 0c99ba1eab63865592bb084feb271cd4e4b0357e, reversing
changes made to 5f92b070bf284f1493b1b5d433dd3adde2f46727.
This caused a CI failure when it landed in master branch due to a
128-bit `@byteSwap` in std.mem.
|
|
|
|
|
|
Some tests are now failing due to debug info changes, some tests
now pass due to improved compiler functionality.
|
|
|
|
|
|
1611 passed; 262 skipped; 0 failed.
(was: 1543 passed; 330 skipped; 0 failed.)
|
|
|
|
|
|
|
|
Signed-off-by: Eric Joldasov <bratishkaerik@getgoogleoff.me>
|
|
Most of this migration was performed automatically with `zig fmt`. There
were a few exceptions which I had to manually fix:
* `@alignCast` and `@addrSpaceCast` cannot be automatically rewritten
* `@truncate`'s fixup is incorrect for vectors
* Test cases are not formatted, and their error locations change
|
|
Signed-off-by: Eric Joldasov <bratishkaerik@getgoogleoff.me>
|
|
|
|
|
|
Implements the ptr_add air tag for spirv.
The implementation for slices is probably wrong, but there seems to be no test for this...
|
|
This instruction is not really working well in the LLVM SPIRV translator,
as it is not implemented.
This commit also intruces the constructStruct helper function to initialize
structs at runtime. This is ALSO buggy in the translator, and we must work
around OpCompositeConstruct not working when some of the constituents are
runtime-known only.
Some other improvements are made:
- improved variable() so that it is more useful and no longer requires the
address space. It always puts values in the Function address space,
and returns a pointer to the Generic address space
- adds a boolToInt utility function
|
|
It turns out that the Khronos LLVM SPIRV translator does not support OpPtrEqual.
Therefore, this instruction is emitted using a series of conversions.
This commit breaks intToEnum, because enum was removed from the arithmetic type
info. The enum should be converted to an int before this function is called.
|
|
make `@call` compile errors match regular calls
|
|
|
|
Closes #12189
|
|
```
$ cat overflow.zig
test {
var a: [1]u65535 = undefined;
_ = a;
}
$ zig-out/bin/zig test overflow.zig
thread 290266 panic: integer overflow
zig/src/type.zig:3604:55: 0xada43d in intAbiAlignment (zig)
std.math.ceilPowerOfTwoPromote(u16, (bits + 7) / 8),
^
zig/src/type.zig:3598:42: 0xadd4ea in intAbiSize (zig)
const alignment = intAbiAlignment(bits, target);
^
zig/src/type.zig:3500:61: 0x92be91 in abiSizeAdvanced (zig)
return AbiSizeAdvanced{ .scalar = intAbiSize(bits, target) };
^
zig/src/type.zig:3385:62: 0x928933 in abiSizeAdvanced (zig)
switch (try payload.elem_type.abiSizeAdvanced(target, strat)) {
^
zig/src/type.zig:3268:32: 0x92c012 in abiSize (zig)
return (abiSizeAdvanced(ty, target, .eager) catch unreachable).scalar;
^
```
This is only noticed in a debug build of zig and silently does the wrong
thing and overflows in release builds.
This happened to `[x]u65529` and above because of the ` + 7` on a `u16`.
|
|
|
|
|
|
|
|
The bitcast of ABI size 1 elements was problematic for some types.
|
|
|
|
change semantics of `@memcpy` and `@memset`
|
|
|
|
* make memset and memset_safe guarantee that if the length is
comptime-known then it will be nonzero.
|
|
and avoid new language feature in std.ArrayList for now, until x86_64
self-hosted backend can implement it.
|
|
|
|
|
|
Also introduce memset_safe AIR tag and support it in C backend and LLVM
backend.
|
|
Now they use slices or array pointers with any element type instead of
requiring byte pointers.
This is a breaking enhancement to the language.
The safety check for overlapping pointers will be implemented in a
future commit.
closes #14040
|
|
|
|
|
|
Bitcast fixes for self-hosted native backends
|
|
Implement missing pointees when ptr is in register.
|
|
|
|
Closes #14506
|
|
These functions are currently footgunny when working with pointers to
arrays and slices. They just return the stated length of the array/slice
without iterating and looking for the first sentinel, even if the
array/slice is a sentinel terminated type.
From looking at the quite small list of places in the standard
library/compiler that this change breaks existing code, the new code
looks to be more readable in all cases.
The usage of std.mem.span/len was totally unneeded in most of the cases
affected by this breaking change.
We could remove these functions entirely in favor of other existing
functions in std.mem such as std.mem.sliceTo(), but that would be a
somewhat nasty breaking change as std.mem.span() is very widely used for
converting sentinel terminated pointers to slices. It is however not at
all widely used for anything else.
Therefore I think it is better to break these few non-standard and
potentially incorrect usages of these functions now and at some later
time, if deemed worthwhile, finally remove these functions.
If we wait for at least a full release cycle so that everyone adapts to
this change first, updating for the removal could be a simple find and
replace without needing to worry about the semantics.
|
|
This enables us to use more efficient loading and storing for these
small stack items
|
|
|