| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
It's discontinued in favor of WASI.
https://github.com/NuxiNL/cloudlibc
|
|
This is a fairly small hobby OS that has not seen development in 2 years. Our
current policy is that hobby OSs should use the `other` tag.
https://github.com/zhmu/ananas
|
|
What is `sparcel`, you might ask? Good question!
If you take a peek in the SPARC v8 manual, §2.2, it is quite explicit that SPARC
v8 is a big-endian architecture. No little-endian or mixed-endian support to be
found here.
On the other hand, the SPARC v9 manual, in §3.2.1.2, states that it has support
for mixed-endian operation, with big-endian mode being the default.
Ok, so `sparcel` must just be referring to SPARC v9 running in little-endian
mode, surely?
Nope:
* https://github.com/llvm/llvm-project/blob/40b4fd7a3e81d32b29364a1b15337bcf817659c0/llvm/lib/Target/Sparc/SparcTargetMachine.cpp#L226
* https://github.com/llvm/llvm-project/blob/40b4fd7a3e81d32b29364a1b15337bcf817659c0/llvm/lib/Target/Sparc/SparcTargetMachine.cpp#L104
So, `sparcel` in LLVM is referring to some sort of fantastical little-endian
SPARC v8 architecture. I've scoured the internet and I can find absolutely no
evidence that such a thing exists or has ever existed. In fact, I can find no
evidence that a little-endian implementation of SPARC v9 ever existed, either.
Or any SPARC version, actually!
The support was added here: https://reviews.llvm.org/D8741
Notably, there is no mention whatsoever of what CPU this might be referring to,
and no justification given for the "but some are little" comment added in the
patch.
My best guess is that this might have been some private exercise in creating a
little-endian version of SPARC that never saw the light of day. Given that SPARC
v8 explicitly doesn't support little-endian operation (let alone little-endian
instruction encoding!), and no CPU is known to be implemented as such, I think
it's very reasonable for us to just remove this support.
|
|
These were for very old OpenCL have been long abandoned in favor of SPIR-V.
* https://github.com/KhronosGroup/SPIR
* https://github.com/KhronosGroup/SPIR-Tools
|
|
Importantly, this ensures that the compiler understands that these ABIs need glibc.
|
|
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`).
|
|
It is very non-obvious that this is what lv2 refers to, and we already use ps4
and ps5 to refer to the later models, so let's just be consistent.
|
|
|
|
There is no obvious reason why this would be relevant for Zig to target. I
rather question the value of LLVM even having target triple code for this, too.
See: https://blog.llvm.org/2010/06/tce-project-co-design-of-application.html
See: https://github.com/cpc/llvmtce
|
|
This was added as an architecture to LLVM's target triple parser and the Clang
driver in 2015. No backend ever materialized as far as I can see (same for GCC).
In 2016, other code referring to it started using "Myriad" instead. Ultimately,
all code related to it that isn't in the target triple parser was removed. It
seems to be a real product, just... literally no one seems to know anything
about the ISA. I figure after almost a decade with no public ISA documentation
to speak of, and no LLVM backend to reference, it's probably safe to assume that
we're not going to learn much about this ISA, making it useless for Zig.
See: https://github.com/llvm/llvm-project/commit/1b5767f72b5a037ca8f1802d737de97f8d92263d
See: https://github.com/llvm/llvm-project/commit/84a7564b28360843ee9afec5d3823c89623eb6a5
See: https://github.com/llvm/llvm-project/commit/8cfe9d8f2ad3a52ba7fd5841d3939aa810536e16
|
|
This seems to just be dead.
See: https://github.com/search?q=repo%3Allvm%2Fllvm-project%20hsail&type=code
See: https://github.com/HSAFoundation/HSAIL-Tools/commits/master
|
|
This is really obscure and no one is 100% sure what it is. It seems to be old
and unused. My suspicion is that it's just an old term for "AMDGPU" before it
was upstreamed to LLVM.
See: https://github.com/search?q=repo%3Allvm%2Fllvm-project+amdil&type=code
|
|
These are quite old GPUs, and it is unlikely that Zig will ever be able to
target them.
See: https://en.wikipedia.org/wiki/Radeon_HD_2000_series
|
|
It's dead: https://developer.android.com/guide/topics/renderscript/migrate
|
|
|
|
This was added to LLVM in 2015 for the LLILC project, which was discontinued in
~2018, and subsequently archived in 2022.
https://github.com/dotnet/llilc/commit/933b58d00ffb4b357956c940b37a379bdf891324
|
|
Native Client is dead.
https://developer.chrome.com/docs/native-client
|
|
kFreeBSD is dead.
https://lists.debian.org/debian-devel/2023/07/msg00176.html
|
|
This was used for LoongArch64, where:
* `gnuf64` -> `ilp32d` / `lp64d` (full hard float)
* `gnuf32` -> `ilp32f` / `lp64f` (hard float for `f32` only)
* `gnusf` -> `ilp32` / `lp64` (soft float)
But Loongson eventually settled on just `gnu` for the first case since that's
what most people will actually be targeting outside embedded scenarios. The
`gnuf32` and `gnusf` specifiers remain in use.
|
|
|
|
* std: Add loongarch support for coff.
See: https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#machine-types
* Update toCoffMachine.
|
|
Fixes #9442.
|
|
|
|
|
|
Closes #20009
|
|
* rename .xros to .visionos as agreed in the tracking issue
* add support for VisionOS platform in the MachO linker
|
|
|
|
This should not be a public API, and the x86 backend does not support
the value 16.
|
|
|
|
* some manual fixes to generated CPU features code. In the future it
would be nice to make the script do those automatically.
* add to various target OS switches. Some of the values I was unsure of
and added TODO panics, for example in the case of spirv CPU arch.
|
|
New OSs:
* XROS
* Serenity
* Vulkan
Removed OSs:
* Ananas
* CloudABI
* Minix
* Contiki
New CPUs:
* spirv
The removed stuff is removed from LLVM but not Zig.
|
|
This version represents "WASI Preview 1".
Closes #19581
|
|
|
|
|
|
This commit changes how we represent comptime-mutable memory
(`comptime var`) in the compiler in order to implement the intended
behavior that references to such memory can only exist at comptime.
It does *not* clean up the representation of mutable values, improve the
representation of comptime-known pointers, or fix the many bugs in the
comptime pointer access code. These will be future enhancements.
Comptime memory lives for the duration of a single Sema, and is not
permitted to escape that one analysis, either by becoming runtime-known
or by becoming comptime-known to other analyses. These restrictions mean
that we can represent comptime allocations not via Decl, but with state
local to Sema - specifically, the new `Sema.comptime_allocs` field. All
comptime-mutable allocations, as well as any comptime-known const allocs
containing references to such memory, live in here. This allows for
relatively fast checking of whether a value references any
comptime-mtuable memory, since we need only traverse values up to
pointers: pointers to Decls can never reference comptime-mutable memory,
and pointers into `Sema.comptime_allocs` always do.
This change exposed some faulty pointer access logic in `Value.zig`.
I've fixed the important cases, but there are some TODOs I've put in
which are definitely possible to hit with sufficiently esoteric code. I
plan to resolve these by auditing all direct accesses to pointers (most
of them ought to use Sema to perform the pointer access!), but for now
this is sufficient for all realistic code and to get tests passing.
This change eliminates `Zcu.tmp_hack_arena`, instead using the Sema
arena for comptime memory mutations, which is possible since comptime
memory is now local to the current Sema.
This change should allow `Decl` to store only an `InternPool.Index`
rather than a full-blown `ty: Type, val: Value`. This commit does not
perform this refactor.
|
|
move `zig libc` command to be lazily built
|
|
part of #19063
This is a prerequisite for doing the same for Resinator.
|
|
|
|
|
|
|
|
These functions have been doomed for a long time. Finally I figured out
what the proper relationship between this API and std.Target is.
|
|
|
|
|
|
|
