| Age | Commit message (Collapse) | Author |
|---|
|
These were leftovers from when we used the LLVM API to create modules.
|
|
It doesn't appear that targeting bridgeOS is meaningfully supported by Apple.
Even LLVM/Clang appear to have incomplete support for it, suggesting that Apple
never bothered to upstream that support. So there's really no sense in us
pretending to support this.
|
|
LLVM doesn't recognize ohoseabi.
|
|
Add PIC/PIE tests and fix some bugs + some improvements to the test harness
|
|
Previously, stepping from the single statement within the loop would
always exit the loop because all of the code unrolled from the loop is
associated with the same line and treated by the debugger as one line.
|
|
This is necessary since isGnuLibC() is true for hurd, so we need to be able to
represent a glibc version for it.
Also add an Os.TaggedVersionRange.gnuLibCVersion() convenience function.
|
|
compiler: Improve handling of `-fno-builtin` and compiler-rt options
|
|
|
|
|
|
|
|
|
|
|
|
We are not using Private variables. This needs to be cleaned up a bit
more, this will happen with the general address space improvements.
|
|
Also cleans up the assembler a bit in general.
|
|
For now the frontend still allows type inputs in assembly. We
might as well resolve them properly in the SPIR-V backend.
|
|
|
|
From `zig build-exe --help`:
-fno-builtin Disable implicit builtin knowledge of functions
It seems entirely reasonable and even expected that this option should imply
both no-builtins on functions (which disables transformation of recognized code
patterns to libcalls) and nobuiltin on call sites (which disables transformation
of libcalls to intrinsics). We now match Clang's behavior for -fno-builtin.
In both cases, we're painting with a fairly broad brush by applying this to an
entire module, but it's better than nothing. #21833 proposes a more fine-grained
way to apply nobuiltin.
|
|
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.
|
|
Add client request support for all architectures supported by Valgrind
|
|
The former prevents recognizing code patterns and turning them into libcalls,
which is what we want for compiler-rt. The latter is meant to be used on call
sites to prevent them from being turned into intrinsics.
Context: https://github.com/ziglang/zig/issues/21833
|
|
|
|
Some follow-up work for #21697
|
|
|
|
Mainly affects amdgcn.
|
|
The old isARM() function was a portability trap. With the name it had, it seemed
like the obviously correct function to use, but it didn't include Thumb. In the
vast majority of cases where someone wants to ask "is the target Arm?", Thumb
*should* be included.
There are exactly 3 cases in the codebase where we do actually need to exclude
Thumb, although one of those is in Aro and mirrors a check in Clang that is
itself likely a bug. These rare cases can just add an extra isThumb() check.
|
|
|
|
|
|
|
|
LLVM doesn't even recognize the gnuilp32 spelling as an alternative.
|
|
Once we upgrade to LLVM 20, these should be lowered verbatim rather than to
simply musl. Similarly, the special case in llvmMachineAbi() should go away.
|
|
Like d1d95294fd657f771657ea671a6984b860347fb0, this is more Apple nonsense where
they abused the arch component of the triple to encode what's really an ABI.
Handling this correctly in Zig's target triple model would take quite a bit of
work. Fortunately, the last Armv7-based Apple Watch was released in 2017 and
these targets are now considered legacy. By the time Zig hits 1.0, they will be
a distant memory. So just remove them.
|
|
|
|
Except Windows, because that just doesn't really fit into LLVM's target triple
format currently.
|
|
Annoyingly, LLVM and Clang have various checks throughout that depend on these
vendor types being set.
|
|
spirv: push constants and small fixes
|
|
|
|
- Rename GPU address spaces to match with SPIR-V spec.
- Emit `Block` Decoration for Uniform/PushConstant variables.
- Don't emit `OpTypeForwardPointer` for non-opencl targets.
(there's still a false-positive about recursive structs)
Signed-off-by: Ali Cheraghi <alichraghi@proton.me>
|
|
This commit reworks how anonymous struct literals and tuples work.
Previously, an untyped anonymous struct literal
(e.g. `const x = .{ .a = 123 }`) was given an "anonymous struct type",
which is a special kind of struct which coerces using structural
equivalence. This mechanism was a holdover from before we used
RLS / result types as the primary mechanism of type inference. This
commit changes the language so that the type assigned here is a "normal"
struct type. It uses a form of equivalence based on the AST node and the
type's structure, much like a reified (`@Type`) type.
Additionally, tuples have been simplified. The distinction between
"simple" and "complex" tuple types is eliminated. All tuples, even those
explicitly declared using `struct { ... }` syntax, use structural
equivalence, and do not undergo staged type resolution. Tuples are very
restricted: they cannot have non-`auto` layouts, cannot have aligned
fields, and cannot have default values with the exception of `comptime`
fields. Tuples currently do not have optimized layout, but this can be
changed in the future.
This change simplifies the language, and fixes some problematic
coercions through pointers which led to unintuitive behavior.
Resolves: #16865
|
|
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.
|
|
spirv: vulkan setup
|
|
|
|
|
|
We can use real pointers with this storage class!!
|
|
* Fragment and Vertex CCs are only valid for SPIR-V when
running under Vulkan.
* Emit GLCompute instead of Kernel for SPIR-V kernels.
|
|
Some improvements to the compiler's handling of function alignment
|
|
Add `is_dll_import` to @extern, to support `__declspec(dllimport)` with the MSVC ABI
|
|
comptime scope.
Add a note about thread local / dll import being the cause.
|
|
|
|
|
|
|
