similar commit from the past:
c73cd05468
This also modifies tools/update-linux-headers.zig to remove these same
files for next time to prevent a regression.
closes#10249
* Add missing Linux headers. Closes#9837
* Update existing headers to latest Linux.
* Consolidate headers that are the same for multiple Zig target CPU
architectures. For example, Linux has only an x86 directory for both
x86_64 and x86 CPU architectures. Now Zig only ships an x86 directory
for Linux headers, and will emit the proper corresponding -isystem
flags.
* tools/update-linux-headers.zig is now available for upgrading to
newer Linux headers, and the update process is now documented on the
wiki.
Conflicts:
* cmake/Findclang.cmake
* cmake/Findlld.cmake
* cmake/Findllvm.cmake
In master branch, more search paths were added to these files with "12"
in the path. In this commit I updated them to "13".
* src/stage1/codegen.cpp
* src/zig_llvm.cpp
* src/zig_llvm.h
In master branch, ZigLLVMBuildCmpXchg is improved to add
`is_single_threaded`. However, the LLVM 13 C API has this already, and
in the llvm13 branch, ZigLLVMBuildCmpXchg is deleted in favor of the C
API. In this commit I updated stage2 to use the LLVM 13 C API rather
than depending on an improved ZigLLVMBuildCmpXchg.
Additionally, src/target.zig largestAtomicBits needed to be updated to
include the new m68k ISA.
Conflicts:
lib/libcxx/include/__config
d57c0cc3bf added support for DragonFlyBSD
to libc++ by updating some ifdefs. This needed to be synced with llvm13.
We already have a LICENSE file that covers the Zig Standard Library. We
no longer need to remind everyone that the license is MIT in every single
file.
Previously this was introduced to clarify the situation for a fork of
Zig that made Zig's LICENSE file harder to find, and replaced it with
their own license that required annual payments to their company.
However that fork now appears to be dead. So there is no need to
reinforce the copyright notice in every single file.
The idea is to depend on this language feature as little as possible
with the hopes that it can be adjusted to be less of an anti-pattern.
This also helps self-hosted, which does not yet implement
`usingnamespace`, get closer to being able to build compiler-rt.
Lakemont has no x86, no MMX, no SSE and no way of handling any fp-math. In theory LLVM is able to implicitly use the soft-float emulation library calls to legalize any such operation but, given Zig's use of many non-standard features, sometimes we hit a weak spot in the X86 codegen backend.
Consider this as a work-around for this LLVM problem, fixing the problem in LLVM is not so high in my todo list as the target is pretty niche and Intel axed it in '19.
(Commit message by @LemonBoy)
* stage1 backend allows configuring the uwtables function attr
via a flag rather than its own logic.
* stage2 defaults to enabling uwtable attr when
linking libunwind, or always on windows
* stage2 makes link_eh_frame_hdr true automatically if uwtable
attr is set to be on for zig functions
* CLI: add -funwind-tables and -fno-unwind-tables to allow the user to
override the defaults.
* hook it up to `zig cc`
closes#9046
- hash/eql functions moved into a Context object
- *Context functions pass an explicit context
- *Adapted functions pass specialized keys and contexts
- new getPtr() function returns a pointer to value
- remove functions renamed to fetchRemove
- new remove functions return bool
- removeAssertDiscard deleted, use assert(remove(...)) instead
- Keys and values are stored in separate arrays
- Entry is now {*K, *V}, the new KV is {K, V}
- BufSet/BufMap functions renamed to match other set/map types
- fixed iterating-while-modifying bug in src/link/C.zig
Conflicts:
* build.zig
* src/Compilation.zig
* src/codegen/spirv/spec.zig
* src/link/SpirV.zig
* test/stage2/darwin.zig
- this one might be problematic; start.zig looks for `main` in the
root source file, not `_main`. Not sure why there is an underscore
there in master branch.
There is a lot left to be desired for this tool, as currently dependencies of extensions and dependencies
of capabilities on extensions are not included:
- There is no machine-readable definition of dependencies of extensions.
- A capability may depend on either of a multitude of extensions, which as of yet cannot be properly
modelled in the target system.
- original PR #7949 (incorrectly) patched a generated-file and changes
have subsequently been lost/overwritten
- fix#7947 in a different way: drop `ppc32` because `ppc` already exists
fix drivers: zig {cc,c++}
- `-dynamiclib` is an alias to `-shared`
- associate `-dynamiclib` with zig `.shared` semantics
fix drivers: zig {cc,c++,build-lib,build-exe}
- use `-dynamic` for {exe,dylib}
- for dylib this fixes a regression
- for exe this replaces incorrect use of `-static`
Clang docs say:
> Like -MMD, but also implies -E and writes to stdout by default.
Previously, Zig handled this option by forwarding it directly to Clang,
and disabling depfiles. However this did not adhere to Clang's documented
behavior of these flags.
Now, in addition to being forwarded directly to Clang, `-MM` also
sets c_out_mode = .preprocessor, just like `-E`.
Another issue I noticed is that Zig did not recognize the aliases for
-MG, -MM, or -MMD. The aliases are now recognized.
This completes the process. All target CPU features are now
auto-generated by the tools/update_cpu_features.zig script, which
contains all the overrides.
Invoking this tool against LLVM 12rc2 now produces an empty git diff.