This includes the latest changes from master branch with fixes to the C
backend that affect aarch64-windows which are necessary to build from
source on this target.
This allows using `zig ar` for `CMAKE_AR`. Unfortunately, it requires a
patch to CMakeLists.txt and cannot be done merely with flags to the
cmake line.
We definitely want a shared lock on a cache hit. Without this, we get a
deadlock when Zig is asked to compile the same C source file multiple
times as part of the same compilation.
This is a partial revert of 8ccb9a6ad327a4d7fbc321b33d4aa66a27a1f5ee.
cc @kcbanner
These bugs were triggered in the C backend by aarch64-specific code in
os/windows.zig. Intentionally not updating zig1.wasm yet because of
upcoming changes and since aarch64-windows is not tested on master yet.
Several <em> elements where added inside a shell node in the
Using--target-and--cflags section. Remove them, since they are not
supposed to be handled by codegen.
For the original commit, see
0c091feb5 (Improve HTML semantics and a11y of language reference).
Fixes#13846
We were missing some math functions. After this enhancement I verified
that I was able to cross-compile ninja.exe for aarch64-windows and
produce a viable binary.
This also no longer uses zstd compression on this file. The reasoning
for this is:
* It has been demonstrated that the release tarballs are actually
smaller if zig1.wasm gets compressed along with the other files
rather than separately compressed.
* More importantly, leaving zig1.wasm uncompressed may result in a
smaller git repository size, since the repository as a whole could
have savings across the multiple versions of zig1.wasm, which would
not be possible if each one was independently compressed.
* When in doubt, do what is simpler, which is to not have this extra
zstd mechanism. This will remove the only "vendored" code from our
build process, which is a nice property to have.
Co-authored-by: Andrew Kelley <andrew@ziglang.org>
On x86 interestingly I can see a reduction in codesize by 1 instruction with this.
While not necessarily faster, it might still reduce codesize a bit and this ordering is also more logical
because it follows ASCII table order. Rust's std uses this ordering too.
See https://zig.godbolt.org/z/PqodY8YqY for the difference.
This makes it so that we no longer use a LUT (Look-Up Table):
* The code is much simpler and easier to understand now.
* Using a LUT means we rely on a warm cache.
Relying on the cache like this results in inconsistent performance and in many cases codegen will be worse.
Also as @topolarity once pointed out, in some cases while it seems like the code may branch, it actually doesn't:
https://github.com/ziglang/zig/pull/11629#issuecomment-1213641429
* Other languages' standard libraries don't do this either.
JFF I wanted to see what other languages codegen compared to us now:
https://rust.godbolt.org/z/Te4ax9Edf, https://zig.godbolt.org/z/nTbYedWKv
So we are pretty much on par or better than other languages now.
