Previously we did not write any missing padding bytes after the smallest
field (either tag or payload, depending on alignment). This resulted in
writing too few bytes and not matching the full abisize of the union.
When storing the address after calculating the element's address,
ensure it's stored in a local with the correct type. Previously it
would incorrectly use the element's type, which could be a float for
example and therefore generate invalid WebAssembly code.
This change also introduces a more robust `store` function.
When the paylaod is zero-sized we must ensure a valid pointer
is still returned for the ptr variation of the instruction. This,
because it's valid to have a pointer to a zero-sized value.
In such a case, we simply return the operand.
For packed unions where its abi size is less than or equal to 8 bytes
we store it directly and don't pass it by reference. This means that
when retrieving the field, we will perform shifts and bitcasts to ensure
the correct type is returned. For larger packed unions, we either allocate
a new stack value based on the field type when the field type is also passed
by reference, or load it directly into a local if it's not.
We currently have `isRef` return true for any type of union, including
packed unions. This means we can simply load it from the data section
to the exact type we want. In the future we can optimize it so it works
similarly to packed structs below 64 bits which do not get stored in
the data section and are not passed by ref.
Previously we would only store the payload, but not the actual tag
that was set. This meant miscompilations where it would incorrectly
return the tag value.
This also adds a tiny optimization for payloads which are not `byRef`
by directly storing them based on offset, rather than first calculating
a pointer to an offset.
Previously it was incorrectly assumed that all memcopy's generated by
the `memcpy` AIR instruction had an element size of 1 byte. However,
this would result in miscompilations for pointer's to arrays where
the element size of the array was larger than 1 byte. We now corectly
calculate this size.
Individual max buffer sizes are well known, now that arithmetic doesn't
require allocations any more.
Also bump `main_cert_pub_key_buf`, so that e.g. `nodejs.org` public
keys can fit.
`-l :path/to/lib.so` behavior on gcc/clang is:
- the path is recorded as-is: no paths, exact filename (`libX.so.Y`).
- no rpaths.
The previous version removed the `:` and pretended it's a positional
argument to the linker. That works in almost all cases, except in how
rules_go[1] does things (the Bazel wrapper for Go).
Test case in #15743, output:
gcc rpath:
0x0000000000000001 (NEEDED) Shared library: [libversioned.so.2]
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/x]
gcc plain:
0x0000000000000001 (NEEDED) Shared library: [libversioned.so.2]
zig cc rpath:
0x0000000000000001 (NEEDED) Shared library: [libversioned.so.2]
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/x]
zig cc plain:
0x0000000000000001 (NEEDED) Shared library: [libversioned.so.2]
Fixes#15743
[1]: https://github.com/bazelbuild/rules_go
These were failing on the prior commit. Unfortunately, the fix would
have been relatively complicated, and ties into underlying issues with
the current incremental compilation logic. After discussing this with
Andrew, we agreed that the best course of action is to completely
disable incremental compilation tests for now until it's more mature, at
which point we can re-enable them.
The idea here is that there are two ways we can reference a function at runtime:
* Through a direct call, i.e. where the function is comptime-known
* Through a function pointer
This means we can easily perform a form of rudimentary escape analysis
on functions. If we ever see a `decl_ref` or `ref` of a function, we
have a function pointer, which could "leak" into runtime code, so we
emit the function; but for a plain `decl_val`, there's no need to.
This change means that `comptime { _ = f; }` no longer forces a function
to be emitted, which was used for some things (mainly tests). These use
sites have been replaced with `_ = &f;`, which still triggers analysis
of the function body, since you're taking a pointer to the function.
Resolves: #6256Resolves: #15353
This data changed quite significantly between DWARF 4 and 5. Some
systems are shipping DWARF 5 libraries (Void Linux on musl libc seems to
use it for crt1 etc), which meant when printing stack traces, a random
compile unit might be incorrectly identified as containing an address,
resulting in incorrect location information.
I was consistently experiencing this issue with compiler stack traces,
and this change fixed it.
