| Age | Commit message (Collapse) | Author |
|---|
|
Closes #12529
Closes #12511
Closes #6835
|
|
|
|
Now the backing integer of a packed struct type may be explicitly
specified with e.g. `packed struct(u32) { ... }`.
|
|
|
|
Fixes: 2a990d696 ("stage1: rework tokenizer to match stage2")
Fixes: b6354ddd5 ("move AST rendering code to separate file")
Signed-off-by: Wei Fu <fuweid89@gmail.com>
|
|
CMake: Improve usage of `llvm-config` (esp. for consistent static/shared linking)
|
|
This is currently unused, but it will be needed soon so that we can
avoid linking static libc++ if LLVM/Clang is configured as a shared
library.
|
|
|
|
|
|
accomodate -> accommodate
|
|
This change is the Zig counterpart to https://reviews.llvm.org/D110413
Since we lower some libcalls directly (just like clang does), we need to
make sure that the ABI we call with matches the ABI of the compiler-rt
we are providing (and also the ABI expected by LLVM).
While I was at it, I noticed some flawed vector handling in the binary
soft float ops in stage 1, so I shored up the logic a bit and expanded
an existing test to cover the missing functionality.
|
|
Calling sprintf() is now triggering an error on Xcode 14.
Using snprintf() is generally not a bad idea anyway.
|
|
|
|
|
|
closes #11996
|
|
stage2 already has this fixed; debug info is given size in bits rather
than ABI size (bytes) multiplied by 8.
closes #11587
|
|
LLVM 14 makes it so that a RHS of saturating shift left produces a
poison value if the value is greater than the number of bits of the LHS.
Zig now emits code that will check if this is the case and select a
saturated LHS value in such case, matching Zig semantics.
|
|
LLVM pointers are transitioning to no longer have types, however, inline
assembly inputs and outputs which accept pointers need to know the
element type. So, inline assembly must be upgraded to add
elementtype(<ty>) annotations.
|
|
|
|
|
|
|
|
see #11946
|
|
closes #11730
|
|
|
|
Prior to this change we would assume the ABI for Apple targets to
be GNU which could result in subtle errors in LLVM emitting calls
to non-existent system libc provided functions such as `_sincosf`
which is a GNU extension and as such is not provided by macOS for example.
This would result in linker errors where the linker would not be
able to find the said symbol in `libSystem.tbd`.
With this change, we now correctly identify macOS (and other Apple
platforms) as having ABI `unknown` which translates to unspecified
in LLVM under-the-hood:
```
// main.ll
target triple = "aarch64-unknown-macos-unknown"
```
Note however that we never suffix the target OS with target version
such as `macos11` or `macos12` which means we fail to instruct LLVM
of potential optimisations provided by the OS such as the availability
of function `___sincosf_stret`. I suggest we investigate that in a
follow-up commit.
|
|
Rename all references of sparcv9 to sparc64, to make Zig align more with
other projects. Also, added new function to convert glibc arch name to Zig
arch name, since it refers to the architecture as sparcv9.
This is based on the suggestion by @kubkon in PR 11847.
(https://github.com/ziglang/zig/pull/11487#pullrequestreview-963761757)
|
|
compiler-rt: avoid symbol collisions with Windows libc
|
|
Closes ziglang/zig#11585
|
|
For example, this allows passing a `*c_longdouble` where a `*f80` is
expected, provided that `c_longdouble` maps to `f80` for this target.
|
|
stage2: change logic for detecting whether the main package is inside
the std package. Previously it relied on realpath() which is not portable.
This uses resolve() which is how imports already work.
* stage2: fix cleanup bug when creating Module
* flatten lib/std/special/* to lib/*
- this was motivated by making main_pkg_is_inside_std false for
compiler_rt & friends.
* rename "mini libc" to "universal libc"
|
|
|
|
Before this change, struct {f80, f80} targeting i386-windows-msvc lowers
to
```llvm
%"std.testing.struct:78:61.6" = type { x86_fp80, [6 x i8], x86_fp80, [6 x i8] }
```
which has an incorrect ABI size of 40. After this change, the struct
lowers to
```llvm
%"std.testing.struct:78:61.6" = type { x86_fp80, [4 x i8], x86_fp80, [4 x i8] }
```
which has the correct ABI size of 32, and properly aligns the second
field to 16 bytes.
The other place that calculates field padding (lowering of constant
values in codegen.cpp) already correctly calls LLVMABISizeOfType
rather than LLVMStoreSizeOfType.
This fixes the compiler-rt tests for i386-windows in this branch.
|
|
|
|
These are only as accurate as f64 even for f128 comptime functions. This
is OK for now; improvements will come with the launch of self-hosted
(#89) and enhancements to compiler-rt implementations.
|
|
Weak aliases don't work on Windows, so we avoid exporting the `l` alias
on this platform for functions we know will collide.
|
|
The reason for having `@tan` is that we already have `@sin` and `@cos`
because some targets have machine code instructions for them, but in the
case that the implementation needs to go into compiler-rt, sin, cos, and
tan all share a common dependency which includes a table of data. To
avoid duplicating this table of data, we promote tan to become a builtin
alongside sin and cos.
ZIR: The tag enum is at capacity so this commit moves
`field_call_bind_named` to be `extended`. I measured this as one of
the least used tags in the zig codebase.
Fix libc math suffix for `f32` being wrong in both stage1 and stage2.
stage1: add missing libc prefix for float functions.
|
|
Updates stage1 to manually lower softfloat operations for all unary
floating point operations, extension/truncation, and arithmetic.
|
|
* std: start removing redundant ResetEvents
* src: fix other uses of std.Thread.ResetEvent
* src: add builtin.sanitize_thread for tsan detection
* atomic: add Atomic.fence for proper fencing with tsan
* Thread: remove the other ResetEvent's and rewrite the current one
* Thread: ResetEvent docs
* zig fmt + WaitGroup.reset() fix
* src: fix build issues for ResetEvent + tsan
* Thread: ResetEvent tests
* Thread: ResetEvent module doc
* Atomic: replace llvm *p memory constraint with *m
* panicking: handle spurious wakeups in futex.wait() when waiting for abort()
* zig fmt
|
|
stage1: Fix packed structs (#2627, #10104)
|
|
This implements basic DWARF output when building for the wasm target.
Stacktraces, however, are currently not supported.
|
|
According to Apple docs, the long double type is a double precision
IEEE754 binary floating-point type, which makes it identical to the
double type. This behavior contrasts to the standard specification,
in which a long double is a quad-precision, IEEE754 binary,
floating-point type.
Thus, we need to take this into account when using the compiler
intrinsics so that we select the correct function version for
FloatMulAdd.
|
|
* The `@bitCast` workaround is removed in favor of `@ptrCast` properly
doing element casting for slice element types. This required an
enhancement both to stage1 and stage2.
* stage1 incorrectly accepts `.{}` instead of `{}`. stage2 code that
abused this is fixed.
* Make some parameters comptime to support functions in switch
expressions (as opposed to making them function pointers).
* Avoid relying on local temporaries being mutable.
* Workarounds for when stage1 and stage2 disagree on function pointer
types.
* Workaround recursive formatting bug with a `@panic("TODO")`.
* Remove unreachable `else` prongs for some inferred error sets.
All in effort towards #89.
|
|
|
|
|
|
Fixed formatting in packed-struct-zig
Skipped packed_structs tests in stage2
simplified packed struct tests
|
|
|
|
|
|
Co-authored-by: Veikka Tuominen <git@vexu.eu>
|
|
|
|
* goals
- zig as linker for object files generated by other compilers
- zig-specific runtime features for eventual standardisation
* changes
- missing routines are marked with `missing`
- structure inspired by libgcc docs, but improved order and wording
- rename misspelled functions
- reorder and rephrase compiler_rt.zig to reflect documentation
- potential decimal float or fixed-point arithmetic support:
* 'Decimal float library routines' ca. 120 functions
* 'Fixed-point fractional library routines' ca. 300 functions
thanks to @Vexu for multiple reviews and @scheibo for review
|
