| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Currently the compiler has two relatively critical bugs in the implementation of
MSVC unwinding:
* #33112 - faults like segfaults and illegal instructions will run destructors
in Rust, meaning we keep running code after a super-fatal exception
has happened.
* #33116 - When compiling with LTO plus `-Z no-landing-pads` (or `-C
panic=abort` with the previous commit) LLVM won't remove all `invoke`
instructions, meaning that some landing pads stick around and
cleanups may be run due to the previous bug.
These both stem from the flavor of "personality function" that Rust uses for
unwinding on MSVC. On 32-bit this is `_except_handler3` and on 64-bit this is
`__C_specific_handler`, but they both essentially are the "most generic"
personality functions for catching exceptions and running cleanups. That is,
thse two personalities will run cleanups for all exceptions unconditionally, so
when we use them we run cleanups for **all SEH exceptions** (include things like
segfaults).
Note that this also explains why LLVM won't optimize away `invoke` instructions.
These functions can legitimately still unwind (the `nounwind` attribute only
seems to apply to "C++ exception-like unwining"). Also note that the standard
library only *catches* Rust exceptions, not others like segfaults and illegal
instructions.
LLVM has support for another personality, `__CxxFrameHandler3`, which does not
run cleanups for general exceptions, only C++ exceptions thrown by
`_CxxThrowException`. This essentially ideally matches our use case, so this
commit moves us over to using this well-known personality function as well as
exception-throwing function.
This doesn't *seem* to pull in any extra runtime dependencies just yet, but if
it does we can perhaps try to work out how to implement more of it in Rust
rather than relying on MSVCRT runtime bits.
More details about how this is actually implemented can be found in the changes
itself, but this...
Closes #33112
Closes #33116
|
|
|
|
cc #31435
|
|
The LLVM change [1] in #32239 unfortunately broke the LLVM build on MinGW, so
this LLVM submodule update brings in one more fix [2] which should hopefully
remedy that.
Once this lands we should be able to immediately start gating on this to prevent
it from happening again.
[1]: https://github.com/rust-lang/llvm/commit/be89e4b5
[2]: https://github.com/rust-lang/llvm/commit/3dcd2c84
|
|
This commit fixes our support for cross compiling a compiler to run on FreeBSD.
Over the weekend I managed to get a cross compiler from Linux to FreeBSD [1]
which I hope to soon use to start producing FreeBSD nightly compilers. With the
`make dist` support added in #32237 we should be able to produce standard
rustc/rust-std packages for FreeBSD through a new slave with this cross compiler.
Currently, however, we don't "Just Work" when cross compiling FreeBSD and a
number of changes were required (part of this PR). They include:
* A few build fixes were needed in LLVM. Our own branch has been rebased on the
actual 3.8 release and I applied one extra commit [2] which contains two fixes:
1. The LLVM CMake build system passes the `-Wl,-z,defs` flag on many
platforms, but *not* when `CMAKE_SYSTEM_NAME` is "FreeBSD". Unfortunately
this doesn't take into account when we're cross compiling, and as predicted
the build will fail if `-Wl,-z,defs` is passed (see [3] for more info). To
fix this we test `TARGET_TRIPLE` instead of the `CMAKE_SYSTEM_NAME` which
is what we're compiling for which fixes the problem.
2. The `PATH_MAX` constant is apparently defined in a different location than
many other Unix systems, so a file which required this just needed some
help to keep compiling.
* Support for compiling compiler-rt with CMake has been added to rustbuild. It
looks like it just emulates Linux in what it compiles as it didn't seem to
naturally produce anything else... At least the architecture is right, so
seems good for now at least!
[1]: https://github.com/alexcrichton/port-of-rust/blob/master/prebuilt/freebsd/Dockerfile
[2]: https://github.com/rust-lang/llvm/commit/be89e4b5
[3]: https://bugs.webkit.org/show_bug.cgi?id=138420
|
|
Looks like they picked up a bunch of fixes, one of which is even quite relevant
to us!
Closes #31505
|
|
This commit rebases our LLVM submodule on the most recent tip of the
`release_38` branch of LLVM. There's been a few fixes and this notably fixes the
assertion error in #31702.
|
|
This brings some routine upgrades to the bundled LLVM that we're using, the most
notable of which is a bug fix to the way we handle range asserts when loading
the discriminant of an enum. This fix ended up being very similar to f9d4149c
where we basically can't have a range assert when loading a discriminant due to
filling drop, and appropriate flags were added to communicate this to
`trans::adt`.
|
|
This pass causes mis-optimizations in some cases and is probably no
longer really important for us, so let's disable it for now.
Fixes #30081
|
|
Fixes #28947
|
|
Travis CI has new infrastructure using the Google Compute Engine which has both
faster CPUs and more memory, and we've been encouraged to switch as it should
help our build times! The only downside currently, however, is that IPv6 is
disabled, causing a number of standard library tests to fail.
Consequently this commit tweaks our travis config in a few ways:
* ccache is disabled as it's not working on GCE just yet
* Docker is used to run tests inside which reportedly will get IPv6 working
* A system LLVM installation is used instead of building LLVM itself. This is
primarily done to reduce build times, but we want automation for this sort of
behavior anyway and we can extend this in the future with building from source
as well if needed.
* gcc-specific logic is removed as the docker image for Ubuntu gives us a
recent-enough gcc by default.
|
|
|
|
This is a rebase of our few small patches on top of the release of LLVM 3.7,
picking up those last few bug fixes on the way up to 3.7!
|
|
There's a number of goodies in this LLVM update:
* This contains a fix for https://llvm.org/bugs/show_bug.cgi?id=23957
which should help us bootstrap farther on 32-bit MSVC targets.
* There is better support for writing multiple flavors of archives, allowing us
to use the built-in LLVM support instead of the system `ar` on all current
platforms of the compiler.
* A number of other minor bug fixes and performance improvements to unblock
various other pieces of work.
|
|
This commit updates the LLVM submodule in use to the current HEAD of the LLVM
repository. This is primarily being done to start picking up unwinding support
for MSVC, which is currently unimplemented in the revision of LLVM we are using.
Along the way a few changes had to be made:
* As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some
significant changes to our RustWrapper.cpp
* As usual, some pass management changed in LLVM, so clang was re-scrutinized to
ensure that we're doing the same thing as clang.
* Some optimization options are now passed directly into the
`PassManagerBuilder` instead of through CLI switches to LLVM.
* The `NoFramePointerElim` option was removed from LLVM, favoring instead the
`no-frame-pointer-elim` function attribute instead.
Additionally, LLVM has picked up some new optimizations which required fixing an
existing soundness hole in the IR we generate. It appears that the current LLVM
we use does not expose this hole. When an enum is moved, the previous slot in
memory is overwritten with a bit pattern corresponding to "dropped". When the
drop glue for this slot is run, however, the switch on the discriminant can
often start executing the `unreachable` block of the switch due to the
discriminant now being outside the normal range. This was patched over locally
for now by having the `unreachable` block just change to a `ret void`.
|
|
|
|
Fixes #22159
Fixes #21721
|
|
I believe that few enough people build from source tarballs that
we don't have to talk about it explicitly.
|
|
Fixes the crash blocking #21886.
|
|
Fixes #22233
|
|
Fixes #21996
|
|
|
|
It got accidentially reverted in 44440e5.
|
|
fmt::Show is for debugging, and can and should be implemented for
all public types. This trait is used with `{:?}` syntax. There still
exists #[derive(Show)].
fmt::String is for types that faithfully be represented as a String.
Because of this, there is no way to derive fmt::String, all
implementations must be purposeful. It is used by the default format
syntax, `{}`.
This will break most instances of `{}`, since that now requires the type
to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the
correct fix. Types that were being printed specifically for users should
receive a fmt::String implementation to fix this.
Part of #20013
[breaking-change]
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #15972 and #16011.
|
|
There should be no more problems during SjLj pass
|
|
Fixes #15793.
|
|
Fixes #11751
|
|
To fix #8106, we need an LLVM version that contains r211082 aka 0dee6756
which fixes a bug that blocks that issue.
There have been some tiny API changes in LLVM, and cmpxchg changed its
return type. The i1 part of the new return type is only interesting when
using the new weak cmpxchg, which we don't do.
|
|
|
|
This comes with a number of fixes to be compatible with upstream LLVM:
* Previously all monomorphizations of "mem::size_of()" would receive the same
symbol. In the past LLVM would silently rename duplicated symbols, but it
appears to now be dropping the duplicate symbols and functions now. The symbol
names of monomorphized functions are now no longer solely based on the type of
the function, but rather the type and the unique hash for the
monomorphization.
* Split stacks are no longer a global feature controlled by a flag in LLVM.
Instead, they are opt-in on a per-function basis through a function attribute.
The rust #[no_split_stack] attribute will disable this, otherwise all
functions have #[split_stack] attached to them.
* The compare and swap instruction now takes two atomic orderings, one for the
successful case and one for the failure case. LLVM internally has an
implementation of calculating the appropriate failure ordering given a
particular success ordering (previously only a success ordering was
specified), and I copied that into the intrinsic translation so the failure
ordering isn't supplied on a source level for now.
* Minor tweaks to LLVM's API in terms of debuginfo, naming, c++11 conventions,
etc.
|
|
Upstream LLVM has changed slightly such that our PassWrapper.cpp no longer
comiles (travis errors). This updates the bundled LLVM to the latest nightly
which will hopefully fix the travis errors we're seeing.
|
|
PR #12407 was accidentally reverted by PR #12411. Restore the correct
version of LLVM that PR #12407 introduced.
|
|
|
|
This updates the LLVM submodule to the `rust-llvm-2014-02-19` tag which is the
old one with https://github.com/rust-lang/llvm/pull/4 cherry-picked on top.
Awesome job by @neykov for this!
|
|
Includes an upstream commit by pcwalton to improve codegen of our enums getting
moved around.
|
|
This upgrade brings commit by @eddyb to help optimizations of virtual calls in
a few places (https://github.com/llvm-mirror/llvm/commit/6d2bd95) as well as a
commit by @c-a to *greatly* improve the runtime of the optimization passes
(https://github.com/rust-lang/llvm/pull/3).
Nice work to these guys!
|
|
|
|
|
|
The main one removed is rust_upcall_reset_stack_limit (continuation of #10156),
and this also removes the upcall_trace function. The was hidden behind a
`-Z trace` flag, but if you attempt to use this now you'll get a linker error
because there is no implementation of the 'upcall_trace' function. Due to this
no longer working, I decided to remove it entirely from the compiler (I'm also a
little unsure on what it did in the first place).
|
|
LLVM's JIT has been updated numerous times, and we haven't been tracking it at
all. The existing LLVM glue code no longer compiles, and the JIT isn't used for
anything currently.
This also rebases out the FixedStackSegment support which we have added to LLVM.
None of this is still in use by the compiler, and there's no need to keep this
functionality around inside of LLVM.
This is needed to unblock #10708 (where we're tripping an LLVM assertion).
|
|
|
|
cc #8488
|
|
* This has one workaround patch (everything's testing just fine...)
* I reworked the fixedstacksegment attribute to be specified with a string
rather than using a keyword and an integer and modifying the parser
* I added a "no-split-stack" attribute along the same lines as the
"fixedstacksegment" attribute for #1226
|
|
Thanks @luqama!
|
