emmalloc.c does a fair amount of type punning in order to access
the size of memory regions and traverse them.
Unfortunately, that can lead to unwanted optimizations.
This simple test case currently triggers a memory fault:
int main(void) {
char * volatile p = malloc(1);
p = realloc(p, 12);
p = malloc(1);
printf("%p\n", p);
}
Work around this by adding "-fno-strict-aliasing" when compiling
that file.
.res files are compiled Windows resource files that get linked into executables/libraries. The linker knows what to do with them, but previously you had to trick Zig into thinking it was an object file (by renaming it to have the .obj extension, for example).
After this commit, the following works:
zig build-exe main.zig resource.res
or, in build.zig:
exe.addObjectFile("resource.res");
Closes#6488
This actually used to be how it worked in stage1, and there was this
issue to change it: #2649
So this commit is a reversal to that idea. One motivation for that issue
was avoiding emitting the panic handler in compilations that do not have
any calls to panic. This commit only resolves the panic handler in the
event of a safety check function being emitted, so it does not have that
flaw.
The other reason given in that issue was for optimizations that elide
safety checks. It's yet to be determined whether that was a good idea or
not; this can get re-explored when we start adding optimization passes
to AIR.
This commit adds these AIR instructions, which are only emitted if
`backendSupportsFeature(.safety_checked_arithmetic)` is true:
* add_safe
* sub_safe
* mul_safe
It removes these nonsensical AIR instructions:
* addwrap_optimized
* subwrap_optimized
* mulwrap_optimized
The safety-checked arithmetic functions push the burden of invoking the
panic handler into the backend. This makes for a messier compiler
implementation, but it reduces the amount of AIR instructions emitted by
Sema, which reduces time spent in the secondary bottleneck of the
compiler. It also generates more compact LLVM IR, reducing time spent in
the primary bottleneck of the compiler.
Finally, it eliminates 1 stack allocation per safety-check which was
being used to store the resulting tuple. These allocations were going to
be annoying when combined with suspension points.
Needed due to the breaking changes to casting builtins, which are used
by the compiler when building itself.
Note from Andrew: I re-ran update-zig1 on my PC and replaced this
commit.
Signed-off-by: Andrew Kelley <andrew@ziglang.org>
Most of this migration was performed automatically with `zig fmt`. There
were a few exceptions which I had to manually fix:
* `@alignCast` and `@addrSpaceCast` cannot be automatically rewritten
* `@truncate`'s fixup is incorrect for vectors
* Test cases are not formatted, and their error locations change
This reverts commit fa6cea22bf9cd5ff6a9dd882166cf7e479acfd6c.
Apologies for the merge. I thought this was a bug fix, but I see that it
is implementing a proposal that I intended to reject.
DeclGen/FuncGen methods are for things that pertain to a particular
declaration or function, while Object methods are for things that
pertain to the entire LLVM Module. Many methods were in the wrong
category, such as type and value lowering.
This is a prerequisite commit for a local branch I am working on, which
needs to be able to call lowerValue() without the context of any
particular function or declaration.
The signature is `getOrCreateSubrange(int64_t Lo, int64_t Count)`, so this updates the bindings to match.
This fixes a crash in `lowerDebugTypeImpl` when analyzing slices that have a length of 2^32 or
larger (up to `2^64 >> 3`, which still crashes, because above that the array size in bits overflows u64).
