Taking a detour trough a f64 is dangerous as the softfloat library
doesn't like converting sNaN values.
The error went unnoticed as an exception is raised by the library but
the stage1 compiler doesn't give a damn.
Happy LLVM 12 Release Day.
Please note that the llvm 12 tag does not include the latest commit in
the release/12.x branch, which is in fact a bug fix for a regression
that is causing a failure in Zig's test suite.
Zig master branch is tracking release/12.x, and will be enabling the
test that is fixed by that commit.
This branch adds "builtin" and "std" to the import table when using the
self-hosted backend.
"builtin" gains one additional item:
```
pub const zig_is_stage2 = true; // false when using stage1 backend
```
This allows the std lib to do conditional compilation based on detecting
which backend is being used. This will be removed from builtin as soon
as self-hosted catches up to feature parity with stage1.
Keep a sharp eye out - people are going to be tempted to abuse this.
The general rule of thumb is do not use `builtin.zig_is_stage2`. However
this commit breaks the rule so that we can gain limited start.zig support
as we incrementally improve the self-hosted compiler.
This commit also implements `fullyQualifiedNameHash` and related
functionality, which effectively puts all Decls in their proper
namespaces. `fullyQualifiedName` is not yet implemented.
Stop printing "todo" log messages for test decls unless we are in test
mode.
Add "previous definition here" error notes for Decl name collisions.
This commit does not bring us yet to a newly passing test case.
Here's what I'm working towards:
```zig
const std = @import("std");
export fn main() c_int {
const a = std.fs.base64_alphabet[0];
return a - 'A';
}
```
Current output:
```
$ ./zig-cache/bin/zig build-exe test.zig
test.zig:3:1: error: TODO implement more analyze elemptr
zig-cache/lib/zig/std/start.zig:38:46: error: TODO implement structInitExpr ty
```
So the next steps are clear:
* Sema: improve elemptr
* AstGen: implement structInitExpr
The current implementation of the target C ABI rules is hopelessly bad,
let's tack some more rules on top in order to prevent some
miscompilations.
Truth to be told the same rule should be applied also to parameters, but
I really can't stand stage1.
LLVM 12 requires sret attributes to have the struct type as a parameter,
and provides no C function for supplying it. Therefore, we must add
another C++ wrapper API for adding the sret attribute.
Fixes ability to build from source in the llvm12 branch.
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
Explicitly set the alignment requirements to 1 (i.e, mark the load as unaligned)
since there are some architectures (e.g SPARCv9) which has different alignment
requirements between a function pointer and usize pointer. On those
architectures, not explicitly setting it will lead into @frameSize generating
usize-aligned load instruction that could crash if the function pointer happens
to be not usize-aligned.
The CLI gains -flto and -fno-lto options to override the default.
However, the cool thing about this is that the defaults are great! In
general when you use build-exe in release mode, Zig will enable LTO if
it would work and it would help.
zig cc supports detecting and honoring the -flto and -fno-lto flags as
well. The linkWithLld functions are improved to all be the same with
regards to copying the artifact instead of trying to pass single objects
through LLD with -r. There is possibly a future improvement here as
well; see the respective TODOs.
stage1 is updated to support outputting LLVM bitcode instead of machine
code when lto is enabled. This allows LLVM to optimize across the Zig and
C/C++ code boundary.
closes#2845
* CLI: change to -mred-zone and -mno-red-zone to match gcc/clang.
* build.zig: remove the double negative and make it an optional bool.
This follows precedent from other flags, allowing the compiler CLI to
be the decider of what is default instead of duplicating the default
value into the build system code.
* Compilation: make it an optional `want_red_zone` instead of a
`no_red_zone` bool. The default is decided by a call to
`target_util.hasRedZone`.
* When creating a Clang command line, put -mred-zone on the command
line if we are forcing it to be enabled.
* Update update_clang_options.zig with respect to the recent {s}/{} format changes.
* `zig cc` integration with red zone preference.
The main idea here is that there are now 2 ways to get a stage1 zig
binary:
* The cmake path. Requirements: cmake, system C++ compiler, system
LLVM, LLD, Clang libraries, compiled by the system C++ compiler.
* The zig path. Requirements: a zig installation, system LLVM, LLD,
Clang libraries, compiled by the zig installation.
Note that the former can be used to now take the latter path.
Removed config.h.in and config.zig.in. The build.zig script no longer is
coupled to the cmake script.
cmake no longer tries to determine the zig version. A build with cmake
will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to
get reverted.
`zig build` now accepts `-Dstage1` which will build the stage1 compiler,
and put the stage2 backend behind a feature flag.
build.zig is simplified to only support the use case of enabling LLVM
support when the LLVM, LLD, and Clang libraries were built by zig. This
part is probably sadly going to have to get reverted to make package
maintainers happy.
Zig build system addBuildOption supports a couple new types.
The biggest reason to make this change is that the zig path is an
attractive option for doing compiler development work on Windows. It
allows people to work on the compiler without having MSVC installed,
using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
This way, in the very situation where a function has a return type
an error union such as `anyerror!void` but doesn't have any erroneous
paths, calling `@errorName` on the unpacked error (which will never
be triggered) will not trip up the static analyzer.
Make gen_const_ptr_struct_recursive aware of the possible presence of
some trailing padding by always bitcasting the pointer to its expected
type.
Not an elegant solution but makes LLVM happy and is consistent with how
the other callsites are handling this case.
Fixes#5398
Make the code used to calculate the variable slot index into the frame
match what's done during the structure layout calculation.
Prevents a few nasty LLVM errors when such types are passed around.
