This gets rid of the super confusing and (as far as I can tell) incorrect
getauxval logic in std.os.linux, and clarifies exactly who owns this state.
The ABI that std now expects is:
extern var __zig_elf_auxv: [*]std.elf.Auxv;
Users can technically override this weak symbol with a strong symbol if they
wish, although I see no particularly useful reason to do so.
It is now a compile error to use std.os.linux.getauxval if libc is linked,
whereas previously it would just give useless results in some cases. I consider
this to be strictly an improvement. Just use std.c.getauxval when linking libc,
which std already does correctly where it needs getauxval.
This code is expected to be further simplified once our baseline Linux version
allows implementing https://codeberg.org/ziglang/zig/issues/31290.
closes https://codeberg.org/ziglang/zig/issues/36203
These have no clear use case, no coherent definition, and incomplete/broken
compiler and linker support.
If actually needed, they can be reintroduced if someone can present a reasonable
use case along with a plan for how they should be implemented consistently in
all backends and linkers.
LLVM requires frontends to lower i128 to <2 x i64> in IR to get the correct
__int128 ABI on x86_64-windows; this is what Clang does. I'm guessing our LLVM
backend didn't do this in the past, which made these hacks necessary. But it
does do so now, so just get rid of this stuff.
As of LLVM 22, most backends can (finally) handle legalization of these types as
necessary, so we don't need to do it ourselves anymore.
closes https://github.com/ziglang/zig/issues/23674
On Windows, it is sometimes problematic to depend on ws2_32.dll. Before,
users of std.Io.Threaded would have to call ioBasic() rather than io()
in order to avoid unnecessary dependencies on ws2_32.dll. Now, the
application can disable networking with std.Options.
This change is necessary due to moving networking functionality to
be based on Io.Operation, which is a tagged union.
use the "symbol" helper function in all exports
move all declarations from common.zig to compiler_rt.zig
flatten the tree structure somewhat (move contents of tiny files into
parent files)
No functional changes.
Our implementation did the classic add-sub rounding trick `(y = x +/- C =+ C - x)`
with `C = 1 / eps(T) = 2^(mantissa - 1)`. This approach only works for values whose
magnitude is below the rounding capacity of the constant. For a 64-bit mantissa
(like f80 has), `C = 2^63` only rounds for `|x| < 2^63`. Before we allowed this to
be ran on `e < bias + 64` aka `|x| < 2^64`. And because it isn't large enough,
we lose a bit to rounding.
For reference, the musl implementation does the same thing, using `mantissa - 1`:
https://git.musl-libc.org/cgit/musl/tree/src/math/ceill.c#n18
where `LDBL_MANT_DIG` is 64 for `long double` on x86.
This commit also combines the floor and ceil implementations into one generic one.
`__addosi4`, `__addodi4`, `__addoti4`, `__subosi4`, `__subodi4`, and
`__suboti4` were all functions which we invented for no apparent reason.
Neither LLVM, nor GCC, nor the Zig compiler use these functions. It
appears the functions were created in a kind of misunderstanding of an
old language proposal; see https://github.com/ziglang/zig/pull/10824.
There is no benefit to these functions existing; if a Zig compiler
backend needs this operation, it is trivial to implement, and *far*
simpler than calling a compiler-rt routine. Therefore, this commit
deletes them. A small amount of that code was used by other parts of
compiler-rt; the logic is trivial so has just been inlined where needed.
I also chose to quickly implement `__addvdi3` (a standard function)
because it is trivial and we already implement the `sub` parallel.
LLVM 21 has started recognizing strlen-like idioms and optimizing them to strlen
calls, so we need this function provided in compiler-rt for libc-less
compilations.
- Combine mulXi3 routines for follow-up cleanup.
- DRY up Dwords and Twords
- rename both to HalveInt and use instance
* Justification: Not all processors have word size 32 bit.
* remove test file from CMakeLists
* DRY things.
Justifications
- compiler_rt base routines are almost finished, so make 1:1
mapping of code and documentation.
- Make adjustments to code + documentation simpler to prevent technical or
documentation debt.
* synchronize zig1.c from zig-wasi external project
* change the way argv works to avoid absolute paths
* autodetect isatty
* compiler_rt: disable some functions when object format is C
* add missing flag from config.zig.in
The next problem is that compiling compiler_rt.c with gcc gives
"conflicting types" errors for `__eqhf2` and friends.
* Rely on libSystem when targeting macOS.
* Make tools/gen_outline_atomics.zig more idiomatic.
* Remove the CPU detection / auxval checking from compiler_rt. This
functionality belongs in a different component. Zig's compiler_rt
must not rely on constructors. Instead it will export a symbol for
setting the value, and start code can detect and activate it.
* Remove the separate logic for inline assembly when the target does or
does not have lse support. `.inst` works in both cases.
cmp.zig was accidently being referenced twice, rather than importing
memcmp.zig. This means that its symbols were also not included in
the generated compiler-rt output.
This moves functions that LLVM generates calls to,
to the compiler_rt implementation itself, rather than c.zig.
This is a prerequisite for native backends to link with compiler-rt.
This also allows native backends to generate calls to `memcpy` and the like.
This change also exposes some of the existing functions under both the
PPC-style names symbols and the compiler-rt-style names, since Zig
currently lowers softfloat calls to the latter.
These are the standard complex multiplication/division functions
required by the C standard (Annex G).
Don't get me started on the standard's handling of complex-infinity...
Alex Rønne Petersen