Previously, you might obtain `-lLLVM-15` from the CMake configuration,
but we might not be able to locate the library if it's not in your
system library path.
Some architectures (AMDGPU) do not support atomic exchange/fetch for
small types (for AMDGPU: 8- and 16-bit ints). For these types
atomic fetch and atomic exchange needs to be implemeted using atomic
operations on a wider type using cmpxchg.
This commit changes the way Zig is intended to deal with variable
declaration for exotic targets. Where previously the idea was to
enfore local/global variables to be placed into their respective
address spaces, depending on the target, this is now fixed to the
generic address space.
To facilitate this for targets where local variables _must_ be
generated into a specific address space (ex. amdgcn where locals
must be generated into the private address space), the variable
allocations (alloca) are generated into the right address space
and then addrspace-casted back to the generic address space. While this
could be less efficient in theory, LLVM will hopefull deal with figuring
out the actual correct address space for a pointer for us. HIP seems to
do the same thing in this regard.
Global variables are handled in a similar way.
build.zig:
- use "-I" instead of "-isystem" for `b.addSearchPrefix()`
main.zig:
- silently ignore superfluous search dirs
- warn when a dir is added to multiple searchlists
- consolidate "expected paramter after {s}" fatal error messages
- rename command-line switch `-dirafter` → `-idirafter`
closes#12888
Ideally this duplicated code could be factored out into a function, but
there doesn't seem to be any way in the Zig type system to represent an
argument to a function called at comptime that is only needed if it is
comptime-known. Instead, we document what is going on in an adjacent
comment in case it gets copy-pasted into new methods in the future.
When trying to allocate memory for functions like `Managed.init` and
`Managed.set` on the stack, a comptime-known allocation size is desired.
The doc comments for these functions indicate that `calcLimbLen` can be
used to determine how many limbs to allocate, but if `value` is not
comptime-known, then neither is `calcLimbLen(value)`. However, an upper
bound on the allocation size is still computable at comptime in this
case, so this note documents an expression that can be used, rather than
trying to add it to every doc comment that mentions `calcLimbLen`.
This implements `@export(a.b, .{..});` in semantic analysis,
allowing users to directly export a variable from a namespace.
* add test case for exporting using field access
This allows converting a comptime_int to an optional integer type, which
either behaves the same as an implicit cast or produces null if the
argument is outside the range of the destination type.
Without the packed qualifier, the type layout that we use to
initialize doesn't match the correct layout of the underlying
storage, causing corrupted data and past-the-end writes.
When testing the Wasm linker for the producers section
we do not ever want to strip the binary as this will remove
the producers section in release-small.
This fixes the CI errors by d086b371f0e21e5029e1b0d05838b87502eb63e6
Thanks to Martin Storsjö for explaining this to me on IRC:
__USE_MINGW_ANSI_STDIO redirects stdio functions towards mingw-w64
reimplementations of them (since msvcrt.dll lacks lots of things). For
x86 with "long double", this is also needed to get long doubles
formatted properly. It's enabled by default by headers when building in
C99 mode, unless you're targeting UCRT. The headers normally enable this
automatically - or you can request it enabled with
-D__USE_MINGW_ANSI_STDIO=1. However, the mingw-w64-crt files are
expected to be built with this explicitly turned off. Since there's a
half dozen various ways of configuring the CRT and various features, the
mingw-w64-crt files specifically need to be built in a very hardcoded
configuration, which is different from how end user source files are
compiled.
This commit removes a patch that we were carrying previously.
See #7356
