| Age | Commit message (Collapse) | Author |
|---|
|
The previous supports_fpic() check was too broad.
|
|
To my knowledge, the only platforms that actually *require* PIE are Fuchsia and
Android, and the latter *only* when building a dynamically-linked executable.
OpenBSD and macOS both strongly encourage using PIE by default, but it isn't
technically required. So for the latter platforms, we enable it by default but
don't enforce it.
Also, importantly, if we're building an object file or a static library, and the
user hasn't explicitly told us whether to build PIE or non-PIE code (and the
target doesn't require PIE), we should *not* default to PIE. Doing so produces
code that cannot be linked into non-PIE output. In other words, building an
object file or a static library as PIE is an optimization only to be done when
the user knows that it'll end up in a PIE executable in the end.
Closes #21837.
|
|
This adds 4 `Legalize.Feature`s:
* `expand_intcast_safe`
* `expand_add_safe`
* `expand_sub_safe`
* `expand_mul_safe`
These do pretty much what they say on the tin. This logic was previously
in Sema, used when `Zcu.Feature.safety_checked_instructions` was not
supported by the backend. That `Zcu.Feature` has been removed in favour
of this legalization.
|
|
Backends can instead ask legalization on a per-instruction basis.
|
|
|
|
|
|
Nothing interesting here; literally just the bare minimum so I can work on this
on and off in a branch without worrying about merge conflicts in the non-backend
code.
|
|
Textual PTX is just assembly language like any other. And if we do ever add
support for emitting PTX object files after reverse engineering the bytecode
format, we'd be emitting ELF files like the CUDA toolchain. So there's really no
need for a special ObjectFormat tag here, nor linker code that treats it as a
distinct format.
|
|
compiler: Allow linking native glibc statically
|
|
|
|
glibc's libc.a depends on the functions provided by libunwind.
|
|
It's about libc++, not libc.
|
|
|
|
These backends are completely unusable at the moment; they can produce neither
assembly files nor object files. So give a nicer error when users try to use
them.
|
|
|
|
|
|
This reverts commit 4fad60fd3a70d0b059ce92ce825faabc1d2ac2e8.
Closes #23056.
|
|
|
|
Closes #21818.
|
|
Emscripten currently implements `emscripten_return_address()` by calling
out into JavaScript and parsing a stack trace, which introduces
significant overhead that we would prefer to avoid in release builds.
This is especially problematic for allocators because the generic parts
of `std.mem.Allocator` make frequent use of `@returnAddress`, even
though very few allocator implementations even observe the return
address, which makes allocators nigh unusable for performance-critical
applications like games if the compiler is unable to devirtualize the
allocator calls.
|
|
The command line flag is only supported in Clang 20: https://github.com/ziglang/zig/issues/23056
This gets rid of some warnings when using zig cc.
|
|
As seen on e.g. Arm/Thumb and MIPS (MIPS16/microMIPS).
Fixes #22888.
|
|
Functions like isMinGW() and isGnuLibC() have a good reason to exist: They look
at multiple components of the target. But functions like isWasm(), isDarwin(),
isGnu(), etc only exist to save 4-8 characters. I don't think this is a good
enough reason to keep them, especially given that:
* It's not immediately obvious to a reader whether target.isDarwin() means the
same thing as target.os.tag.isDarwin() precisely because isMinGW() and similar
functions *do* look at multiple components.
* It's not clear where we would draw the line. The logical conclusion before
this commit would be to also wrap Arch.isX86(), Os.Tag.isSolarish(),
Abi.isOpenHarmony(), etc... this obviously quickly gets out of hand.
* It's nice to just have a single correct way of doing something.
|
|
This allows it to inspect CPU features which is needed for Propeller, and AVR in
the future.
|
|
Allows deduplicating the code in Sema.
|
|
|
|
This was for a hobby project that appears to be dormant for now. This can be
added back if the project is resumed in the future.
|
|
This is all of the expected 0.14.0 progress on #21530, which can now be
postponed once this commit is merged.
This required rewriting the (un)wrap operations since the original
implementations were extremely buggy.
Also adds an easy way to retrigger Sema OPV bugs so that I don't have to
keep updating #22419 all the time.
|
|
|
|
Sema is arbitrarily scalarizing some operations, which means that when I
try to implement vectorized versions of those operations in a backend,
they are impossible to test due to Sema not producing them. Now, I can
implement them and then temporarily enable the new feature for that
backend in order to test them. Once the backend supports all of them,
the feature can be permanently enabled.
This also deletes the Air instructions `int_from_bool` and
`int_from_ptr`, which are just bitcasts with a fixed result type, since
changing `un_op` to `ty_op` takes up the same amount of memory.
|
|
LLVM.
See 652c5151429e279f70396ee601416c87a70c1bec. Better to avoid relying on default
LLVM behavior going forward.
|
|
Necessary because of: https://github.com/llvm/llvm-project/commit/dc665fa5f5b8b572479ceac6bf32e0174de65f1e
|
|
This moves the default value logic to Package.Module.create() instead and makes
it so that Compilation.Config.any_unwind_tables is computed similarly to
any_sanitize_thread, any_fuzz, etc. It turns out that for any_unwind_tables, we
only actually care if unwind tables are enabled at all, not at what level.
|
|
|
|
The blocker for enabling this feature was my need to debug the emitted
assembly without debug info and having to manually inspect memory to
determine struct contents. However, we now have debug info!
(lldb) v -L foo bar
0x00007fffffffda20: (repro.repro.Foo) foo = {
0x00007fffffffda24: .x = 12
0x00007fffffffda20: .y = 34
}
0x00007fffffffda28: (repro.repro.Bar) bar = {
0x00007fffffffda28: .x = 56
0x00007fffffffda2c: .y = 78
}
Updates #21530
|
|
|
|
|
|
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 is a GCC library providing symbols with stack smashing protection. We
provide (most of) these symbols in our compiler-rt.
|
|
This is GCC's equivalent to compiler-rt. The two libraries have a huge overlap
in exported symbols, so we may as well satisfy it this way to increase
compatibility with build systems in the wild.
|
|
This is GCC's take on libunwind. We can satisfy it by way of our bundled LLVM
libunwind implementation.
Closes #17268.
|
|
The real libgcc_s is a compiler-provided library; it works just fine with both
glibc and musl. There's no reason that I can see for this check to be limited to
glibc-based targets.
|
|
This is a library that ships with GCC and provides fallback implementations of
atomic intrinsics where necessary. Since we do the same in our compiler-rt
implementation, and since some build systems insist on passing -latomic even
for Clang (which zig cc masquerades as), just satisfy this dependency by way of
compiler-rt.
Closes #22165.
|
|
compiler: Improve handling of `-fno-builtin` and compiler-rt options
|
|
|
|
Clang only uses the system assembler for nvptx and xcore nowadays.
|
|
|
|
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.
|
|
`std.Target.Cpu.Model`: Further refinements to `generic()` and `baseline()`
|
