| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Fixes the compiler build for various targets, especially 32-bit.
|
|
|
|
Also add a static_assert to catch future alignment mismatches on this type, and
reflect recent layout changes in the Zig bindings.
|
|
Fixes failing tarball builds for x86-linux and x86-windows.
The MSVC special case here is very sus, but that's a problem for another day.
|
|
|
|
Co-authored-by: David Rubin <daviru007@icloud.com>
|
|
|
|
|
|
release/18.x branch, commit 78b99c73ee4b96fe9ce0e294d4632326afb2db42
|
|
|
|
This wasn't caught due to missing C++ static asserts for this enum. This
commit adds them and fixes the enum.
|
|
release/17.x branch, commit 8f4dd44097c9ae25dd203d5ac87f3b48f854bba8
|
|
|
|
|
|
Superceeds PR #12735 (now supporting all packed structs in GNU C)
Fixes issue #12733
This stops translating C packed struct as a Zig packed struct.
Instead use a regular `extern struct` with `align(1)`.
This is because (as @Vexu explained) Zig packed structs are really just integers (not structs).
Alignment issue is more complicated. I think @ifreund was the
first to notice it in his comment on PR #12735
Justification of my interpretion of the C(lang) behavior
comes from a careful reading of the GCC docs for type & variable attributes:
(clang emulates gnu's packed attribute here)
The final line of the documentation for __attribute__ ((aligned)) [on types] says:
> When used on a struct, or struct member, *the aligned attribute can only increase the alignment*; in order to decrease it, the packed attribute must be specified as well.
This implies that GCC uses the `packed` attribute for alignment purposes
in addition to eliminating padding.
The documentation for __attribute__((packed)) [on types], states:
> This attribute, attached to a struct, union, or C++ class type definition, specifies that each of its members (other than zero-width bit-fields) is placed to minimize the memory required. **This is equivalent to specifying the packed attribute on each of the members**.
The key is resolving this indirection, and looking at the documentation
for __attribute__((packed)) [on fields (wierdly under "variables" section)]:
> The packed attribute specifies that a **structure member should have the smallest possible alignment** — one bit for a bit-field and one byte otherwise, unless a larger value is specified with the aligned attribute. The attribute does not apply to non-member objects.
Furthermore, alignment is the only effect of the packed attribute mentioned in the GCC docs (for "common" architecture).
Based on this, it seems safe to completely substitute C 'packed' with Zig 'align(1)'.
Target-specific or undocumented behavior potentially changes this.
Unfortunately, the current implementation of `translate-c` translates as
`packed struct` without alignment info.
Because Zig packed structs are really integers (as mentioned above),
they are the wrong interpretation and we should be using 'extern struct'.
Running `translate-c` on the following code:
```c
struct foo {
char a;
int b;
} __attribute__((packed));
struct bar {
char a;
int b;
short c;
__attribute__((aligned(8))) long d;
} __attribute__((packed));
```
Previously used a 'packed struct' (which was not FFI-safe on stage1).
After applying this change, the translated structures have align(1)
explicitly applied to all of their fields AS EXPECTED (unless explicitly overriden).
This makes Zig behavior for `tranlsate-c` consistent with clang/GCC.
Here is the newly produced (correct) output for the above example:
```zig
pub const struct_foo = extern struct {
a: u8 align(1),
b: c_int align(1),
};
pub const struct_bar = extern struct {
a: u8 align(1),
b: c_int align(1),
c: c_short align(1),
d: c_long align(8),
};
```
Also note for reference: Since the last stable release (0.9.1),
there was a change in the language spec
related to the alignment of packed structures.
The docs for Zig 0.9.1 read:
> Packed structs have 1-byte alignment.
So the old behavior of translate-c (not specifying any alignment) was possibly correct back then.
However the current docs read:
> Packed structs have the same alignment as their backing integer
Suggsestive both to the change to an integer-backed representation
which is incompatible with C's notation.
|
|
|
|
|
|
This check is needed because if static/dynamic linking is mixed incorrectly,
it's possible for Clang and LLVM to end up with duplicate "copies" of libc++.
This is not benign: Static variables are not shared, so equality comparisons
that depend on pointers to static variables will fail. One such failure is
std::generic_category(), which causes POSIX error codes to compare as unequal
when passed between LLVM and Clang.
I believe this is the cause of https://github.com/ziglang/zig/issues/11168
In order to avoid affecting build times when Zig is repeatedly invoked,
we only enable this check for "zig env" and "zig version"
|
|
|
|
This reverts commit 22cb6938891c73d64b749a2516c8eaf79aa25b03.
|
|
|
|
For parameters and return types of functions with the C calling
convention, the LLVM backend now has a special lowering for the function
type that makes the function adhere to the C ABI. The AIR instruction
lowerings for call, ret, and ret_load are adjusted to bitcast the real
type to the ABI type if necessary.
More work on this will need to be done, however, this improvement is
enough that stage3 now passes all the same behavior tests that stage2
passes - notably, translate-c no longer has a segfault due to C ABI
issues with Zig's Clang C API wrapper.
|
|
|
|
Fixes #10955
|
|
* zig_clang is fully updated
* zig_llvm is fully updated
Some initial work on codegen.cpp is in place for upgrading to LLVM's
new opaque pointers. However there is much more to be done.
A few of zig llvm bindings for deprecated functions have been updated;
more need to be updated.
|
|
|
|
|
|
Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>
Co-authored-by: Josh Soref <jsoref@users.noreply.github.com>
|
|
|
|
#8589 introduced correct handling of signed (possibly negative) array access
of pointers. Since unadorned integer literals in C are signed, this resulted
in inefficient generated code when indexing a pointer by a non-negative
integer literal.
|
|
|
|
Translate enum types as the underlying integer type. Translate enum constants
as top-level integer constants of the correct type (which does not necessarily
match the enum integer type).
If an enum constant's type cannot be translated for some reason, omit it.
See discussion https://github.com/ziglang/zig/issues/2115#issuecomment-827968279
Fixes #9153
|
|
Don't move static local variables into the top-level scope since this
can cause name clashes if subsequently-defined variables or parameters
in different scopes share the name.
Instead, use a variable within a struct so that the variable's lexical
scope does not change. This solution was suggested by @LemonBoy
Note that a similar name-shadowing problem exists with `extern` variables
declared within block scope, but a different solution will be needed since
they do need to be moved to the top-level scope and we can't rename them.
|
|
Fixes #8759
|
|
Fixes O(N^2) behavior of `transPreprocessorEntities` due to repeated calls to
`mem.len`
Closes #8959
|
|
Use a `defer` statement to implement the C __cleanup__ attribute.
See https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html
|
|
|
|
When trying to retrieve 80bit fp values from clang using
getValueAsApproximateDouble we'd eventually hit the ceiling value and
return infinity, an invalid value for a fp literal.
Add some logic to prevent this error and warn the user.
Closes #8602
|
|
|
|
Includes vector types, __builtin_shufflevector, and __builtin_convertvector
|
|
|
|
Enables translation of C code that uses the `_Generic` keyword
|
|
|
|
|
|
|
|
Add support for OffsetOfExpr that contain exactly 1 component, when that component
is a field.
For example, given:
```c
struct S {
float f;
double d;
};
struct T {
long l;
int i;
struct S s[10];
};
```
Then:
```c
offsetof(struct T, i) // supported
offsetof(struct T, s[2].d) // not supported currently
```
|
|
|
|
|
|
Conflicts:
* src/clang.zig
* src/llvm.zig
- this file got moved to src/llvm/bindings.zig in master branch so I
had to put the new LLVM arch/os enum tags into it.
* lib/std/target.zig, src/stage1/target.cpp
- haiku had an inconsistency with its default target ABI, gnu vs
eabi. In this commit we make it gnu in both places to match the
latest changes by @hoanga.
* src/translate_c.zig
|
