| Age | Commit message (Collapse) | Author | Lines |
|
|
|
This change will fix the issue from
https://github.com/japaric/svd2rust/pull/130
|
|
This still does not work on 32-bit archs because of an LLVM limitation,
but this is only an optimization, so let's push it on 64-bit only for now.
Fixes #37945
|
|
This commit implements stack probes on x86/x86_64 using the freshly landed
support upstream in LLVM. The purpose of stack probes here are to guarantee a
segfault on stack overflow rather than having a chance of running over the guard
page already present on all threads by accident.
At this time there's no support for any other architecture because LLVM itself
does not have support for other architectures.
|
|
Fixes #42893.
|
|
check for some targets, notably ARMv6-M.
|
|
Fixes #40883.
|
|
So ARM had quite a few codegen bugs on LLVM 4.0 which are fixed on LLVM
trunk. This backports 5 of them:
r297871 - ARM: avoid clobbering register in v6 jump-table expansion.
- fixes rust-lang/rust#42248
r294949 - [Thumb-1] TBB generation: spot redefinitions of index
r295816 - [ARM] Fix constant islands pass.
r300870 - [Thumb-1] Fix corner cases for compressed jump tables
r302650 - [IfConversion] Add missing check in
IfConversion/canFallThroughTo
- unblocks rust-lang/rust#39409
|
|
|
|
Includes https://github.com/rust-lang/llvm/pull/80
Includes https://github.com/rust-lang/llvm/pull/79
Also adds tests and thus fixes #24194
|
|
This change will allow rust code to have proper support for division
and multiplication using libgcc libcalls.
|
|
|
|
The bug was reported by @akovaski here:
https://github.com/rust-embedded/rfcs/issues/20#issuecomment-296482148
|
|
|
|
|
|
|
|
|
|
Fixes #40593.
|
|
pick up a fix to LLVM PR29151.
|
|
|
|
|
|
fixes #38406
|
|
Fixes #37829
|
|
|
|
|
|
Update subproject commit.
|
|
GetCaseResults"
|
|
|
|
pass.
|
|
|
|
Fixes #36474
|
|
|
|
|
|
|
|
Point llvm @bitshifter branch until PR accepted
Use today's date for LLVM auto clean trigger
Update LLVM submodule to point at rust-lang fork.
Handle case when target is set
|
|
|
|
@tmiasko did some digging and discovered that
https://reviews.llvm.org/D22858 may be relevant.
|
|
|
|
|
|
The 3.9 release of LLVM isn't out yet, but this moves us onto that branch to
start tracking it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Picks up the fix for PR28005
|
|
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
|