| Age | Commit message (Collapse) | Author |
|---|
|
|
|
LLD expects the library file name (minus extension) to be exactly libmingw32. By
calling it mingw32 previously, we prevented it from being detected as being in
LLD's list of libraries that are excluded from the MinGW-specific auto-export
mechanism.
https://github.com/llvm/llvm-project/blob/b9d27ac252265839354fffeacaa8f39377ed7424/lld/COFF/MinGW.cpp#L30-L56
As a result, a DLL built for *-windows-gnu with Zig would export a bunch of
internal MinGW symbols. This sometimes worked out fine, but it could break at
link or run time when linking an EXE with a DLL, where both are targeting
*-windows-gnu and thus linking separate copies of mingw32.lib. In #23204, this
manifested as the linker getting confused about _gnu_exception_handler() because
it was incorrectly exported by the DLL while also being defined in the
mingw32.lib that was being linked into the EXE.
Closes #23204.
|
|
|
|
* compiler-rt and mingw32 have both run into LLD bugs, and LLVM disables LTO for
its compiler-rt, so disable LTO for these.
* While we haven't run into any bugs in it, LLVM disables LTO for its libtsan,
so follow suit just to be safe.
* Allow LTO for libfuzzer as LLVM does.
|
|
|
|
|
|
Closes #22475.
|
|
It should not use the CRT ones, and it also needs a few flags of its own that I
forgot to add in #22156.
Follow-up fix for #10989.
|
|
|
|
The goal here is to support both levels of unwind tables (sync and async) in
zig cc and zig build. Previously, the LLVM backend always used async tables
while zig cc was partially influenced by whatever was Clang's default.
|
|
This option, by its very nature, needs to be attached to a module. If it isn't,
the code in a module could break at random when compiled into an application
that doesn't have this option set.
After this change, skip_linker_dependencies no longer implies no_builtin in the
LLVM backend.
|
|
addCCArgs() will then pass the appropriate flag to Clang.
|
|
|
|
LLVM recently introduced new Triple::ArchType members in 19.1.3 which broke our
static assertions in zig_llvm.cpp. When implementing a fix for that, I realized
that we don't even need a lot of the stuff we have in zig_llvm.(cpp,h) anymore.
This commit trims the interface down considerably.
|
|
Embrace the Path abstraction, doing more operations based on directory
handles rather than absolute file paths. Most of the diff noise here
comes from this one.
Fix sorting of crtbegin/crtend atoms. Previously it would look at all
path components for those strings.
Make the C runtime path detection partially a pure function, and move
some logic to glibc.zig where it belongs.
|
|
ref: adfd13c6ffb563b1379052b92f6ae4148b91cc12
|
|
Also remove mentions of arm, armeb, thumbeb, and aarch64_be; none of these are
relevant for Windows.
|
|
This is a misfeature that we inherited from LLVM:
* https://reviews.llvm.org/D61259
* https://reviews.llvm.org/D61939
(`aarch64_32` and `arm64_32` are equivalent.)
I truly have no idea why this triple passed review in LLVM. It is, to date, the
*only* tag in the architecture component that is not, in fact, an architecture.
In reality, it is just an ILP32 ABI for AArch64 (*not* AArch32).
The triples that use `aarch64_32` look like `aarch64_32-apple-watchos`. Yes,
that triple is exactly what you think; it has no ABI component. They really,
seriously did this.
Since only Apple could come up with silliness like this, it should come as no
surprise that no one else uses `aarch64_32`. Later on, a GNU ILP32 ABI for
AArch64 was developed, and support was added to LLVM:
* https://reviews.llvm.org/D94143
* https://reviews.llvm.org/D104931
Here, sanity seems to have prevailed, and a triple using this ABI looks like
`aarch64-linux-gnu_ilp32` as you would expect.
As can be seen from the diffs in this commit, there was plenty of confusion
throughout the Zig codebase about what exactly `aarch64_32` was. So let's just
remove it. In its place, we'll use `aarch64-watchos-ilp32`,
`aarch64-linux-gnuilp32`, and so on. We'll then translate these appropriately
when talking to LLVM. Hence, this commit adds the `ilp32` ABI tag (we already
have `gnuilp32`).
|
|
|
|
|
|
|
|
|
|
|
|
Closes https://github.com/ziglang/zig/issues/19284
As of 9f2cb920c055bc990cc9d593b8dc9eaa450d07b9 configuring the global
cache directory to a relative path causes errors of the following form
when cross compiling to `windows-gnu`.
```
error: unable to generate DLL import .lib file for kernel32: FileNotFound
```
The issue occurred because the `def_final_path` included the global
cache path as a prefix and later on the `def_final_file` was created
using that path with the global cache directory handle.
|
|
Fixes a mismatch where the manifests would be written to the local cache dir, but the .def/.lib files themselves would be written to the global cache dir. This meant that if you cleared your global cache, your local cache would still think that the .lib files existed in the cache and it'd lead to 'No such file or directory' errors at linktime.
This mismatch was introduced in the stage1 -> stage2 transition of this code.
|
|
|
|
|
|
I observed a duplicate symbol linker error; pow was defined both by
mingwex.lib and ucrtbase.dll.
|
|
Separate commits for the zig logic and the copied files.
|
|
Martin Storsjö kindly took the time to discuss things at length with me,
and the results are that this status quo is correct. I added comments so
that I don't think it should be changed later.
|
|
|
|
Upstream commit dddccbc3ef50ac52bf00723fd2f68d98140aab80
* adds ucrtbase.def.in
* mingwex: replace mingw crt files with ucrt files
* adds missing mingw-w64 ucrt files
The rules that govern which set of files are included or excluded is
contained in the logic for tools/update_mingw.zig
|
|
|
|
Fixes "building import libs not included in core functionality" when
bootstrapping on Windows.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Closes #17753
|
|
|
|
|
|
|
|
* move `ptrBitWidth` from Arch to Target since it needs to know about the abi
* double isn't always 8 bits
* AVR uses 1-byte alignment for everything in GCC
|
|
This makes progress be exposed to the top-level caller of update().
I tossed in a bonus change: when the `zig build` subcommand sees exit
code 2, it omits the "following command failed" line, and the build
runner uses exit code 2 when there are compile errors. This tidies up
the output on build failure by a little bit.
|
|
Introduces std.zig.ErrorBundle which is a trivially serializeable set
of compilation errors. This is in the standard library so that both
the compiler and the build runner can use it. The idea is they will
use it to communicate compilation errors over a binary protocol.
The binary encoding of ErrorBundle is a bit problematic - I got a little
too aggressive with compaction. I need to change it in a follow-up
commit to use some indirection in the error message list, otherwise
iteration is too unergonomic. In fact it's so problematic right now that
the logic getAllErrorsAlloc() actually fails to produce a viable
ErrorBundle because it puts SourceLocation data in between the root
level ErrorMessage data.
This commit has a simplification - redundant logic for rendering AST
errors to stderr has been removed in favor of moving the logic for
lowering AST errors into AstGen. So even if we get parse errors, the
errors will get lowered into ZIR before being reported. I believe this
will be useful when working on --autofix. Either way, some redundant
brittle logic was happily deleted.
In Compilation, updateSubCompilation() is improved to properly perform
error reporting when a sub-compilation object fails. It no longer dumps
directly to stderr; instead it populates an ErrorBundle object, which
gets added to the parent one during getAllErrorsAlloc().
In package fetching code, instead of dumping directly to stderr, it now
populates an ErrorBundle object, and gets properly reported at the CLI
layer of abstraction.
|
|
|
|
|
|
__LIBMSVCRT__ is still used and is distinct from __LIBMSVCRT_OS__
|
