| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 352712
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Set default `ASAN_OPTIONS` when running libFuzzer tests. This allows us
to remove special casing in code for Darwin where we usually pass
`abort_on_error=0` to override platform defaults for tests.
A previous commit changed the code to make the tests pass:
https://github.com/llvm/llvm-project/commit/7764a04af007eca68eafcf5caaea560ed05e35a9
Adapted a few tests to use `%env_asan_opts=` instead of directly setting
the environment variable.
rdar://problem/47515276
Reviewers: kcc, george.karpenkov
Differential Revision: https://reviews.llvm.org/D57465
llvm-svn: 352711
|
| |
|
|
| |
llvm-svn: 352710
|
| |
|
|
| |
llvm-svn: 352709
|
| |
|
|
|
|
|
|
| |
mode only intrinsics to avx512-intrinsics-x86_64.ll.
Most of the other intrinsic tests have a 32-bit command lines.
llvm-svn: 352708
|
| |
|
|
| |
llvm-svn: 352707
|
| |
|
|
|
|
|
|
| |
One considers it integer division, the other doesn't.
Move to `//` (floor division) so that this test passes
independently from the version.
llvm-svn: 352706
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D57436
llvm-svn: 352705
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVMConfig.with_environment() uses os.path.normcase(os.path.normpath(x)) to
normalize temporary env vars. LLVMConfig.use_clang() uses with_environment() to
temporarily set PATH and then look for clang there. This means that on Windows,
clang will be run with a path like c:\foo\bin\clang.EXE (with a lower-case
"C:").
lit.util.which() used to not do this, which means the executables added in
clang/test/lit.cfg.py (e.g. c-index-test) were run with a path like
C:\foo\bin\c-index-test.EXE (because both CMake and GN happen to write
clang_tools_dir with an upper-case C to lit.site.cfg.py).
clang/test/Index/pch-from-libclang.c requires that both c-index-test and clang
use _exactly_ the same resource dir path (same case and everything), because a
hash of the resource directory is used as module cache path.
This patch is necessary but not sufficient to make pch-from-libclang.c pass on
Windows.
Differential Revision: https://reviews.llvm.org/D57343
llvm-svn: 352704
|
| |
|
|
|
|
| |
This will ensure we don't rerun Sphinx when the files exist.
llvm-svn: 352703
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fixes PR40267, in which the removed assertion was triggering on
perfectly valid IR. As far as I can tell, constant out of bounds
indices should be allowed when splitting extract_vector_elt, since
they will simply be propagated as out of bounds indices in the
resulting split vector and handled appropriately elsewhere.
Reviewers: aheejin
Subscribers: dschuff, sbc100, jgravelle-google, hiraditya
Differential Revision: https://reviews.llvm.org/D57471
llvm-svn: 352702
|
| |
|
|
|
|
|
| |
So, we need an explicit call to decode() here to let it work with
both interpreters. Fixes TestXMMRegisters on 3.7.
llvm-svn: 352701
|
| |
|
|
|
|
| |
default. Posix-only for now, tested on Linux
llvm-svn: 352700
|
| |
|
|
|
|
|
|
|
|
| |
default case of some type legalization handlers that can be reached with intrinsics with result or operands that aren't legal types.
These can be triggered by mistakenly using a 64-bit mode only intrinsics with a -mtriple=i686. Using report_fatal_error gives a better experience for this mistake in release builds instead of probably crashing.
We already do this for some of the vector type legalization handles.
llvm-svn: 352699
|
| |
|
|
|
|
| |
I believe this was there to handle avx512bw intrinsics that returned i64 type in 32-bit mode. But all those intrinsics have since been changed to v64i1 results or replaced with generic IR.
llvm-svn: 352698
|
| |
|
|
| |
llvm-svn: 352697
|
| |
|
|
|
|
|
| |
This patch adds the lldb-docs target which generates the Sphinx html
documentation.
llvm-svn: 352696
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We planned to delete this intrinsic and do custom lowering from
`wasm.get.exception`, which has a token argument, to
`EXTRACT_EXCEPTION`, a wasm pseudo instruction that simulates popping a
value from the wasm stack.
To do that, we need to introduce a new `WebAssemblyISD` node for this,
which itself is not a problem, but also have to introduce the
`WebAssemblyISD` namespace in SelectionDAGBuilder.cpp. I don't think any
other targets are doing that in the file. And also putting a
target-specific intrinsic in the common file is a little weird too. (All
other intrinsic functions in this `visitIntrinsicCall` functions are not
target-specific ones. Other target-specific intrinsics are usually
handled in `lib/Target/[TargetName]/[TargetName]ISelLowering.cpp`. The
reason we can't do this is it has a token argument.
Anyway, so I think I prefer the current code with one redundant
intrinsic more than adding one more `WebAssemblyISD` node and
also introducing the `WebAssemblyISD` namespace into
SelectionDAGBuilder.cpp. What do you think?
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D57480
llvm-svn: 352695
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ELF sections allow 0 for the alignment, which is specified to
be the same as 1. However many clients do not expect this and
will behave poorly in the presence of a 0-aligned section (for
example by trying to modulo something by the section alignment).
We can be more polite by making sure that we always pass a
non-zero value to clients.
Differential Revision: https://reviews.llvm.org/D57482
llvm-svn: 352694
|
| |
|
|
|
|
| |
Accidentally left this dependency out after D54438.
llvm-svn: 352693
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This teaches the legalizer to handle G_FEXP in AArch64. As a result, it also
allows us to select G_FEXP.
It...
- Updates the legalizer-info tests
- Adds a test for legalizing exp
- Updates the existing fp tests to show that we can now select G_FEXP
https://reviews.llvm.org/D57483
llvm-svn: 352692
|
| |
|
|
|
|
| |
No test as it's a preventative fix.
llvm-svn: 352691
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`noreturn` calls
Summary:
UBSan wants to detect when unreachable code is actually reached, so it
adds instrumentation before every unreachable instruction. However, the
optimizer will remove code after calls to functions marked with
noreturn. To avoid this UBSan removes noreturn from both the call
instruction as well as from the function itself. Unfortunately, ASan
relies on this annotation to unpoison the stack by inserting calls to
_asan_handle_no_return before noreturn functions. This is important for
functions that do not return but access the the stack memory, e.g.,
unwinder functions *like* longjmp (longjmp itself is actually
"double-proofed" via its interceptor). The result is that when ASan and
UBSan are combined, the noreturn attributes are missing and ASan cannot
unpoison the stack, so it has false positives when stack unwinding is
used.
Changes:
Clang-CodeGen now directly insert calls to `__asan_handle_no_return`
when a call to a noreturn function is encountered and both
UBsan-unreachable and ASan are enabled. This allows UBSan to continue
removing the noreturn attribute from functions without any changes to
the ASan pass.
Previously generated code:
```
call void @longjmp
call void @__asan_handle_no_return
call void @__ubsan_handle_builtin_unreachable
```
Generated code (for now):
```
call void @__asan_handle_no_return
call void @longjmp
call void @__asan_handle_no_return
call void @__ubsan_handle_builtin_unreachable
```
rdar://problem/40723397
Reviewers: delcypher, eugenis, vsk
Differential Revision: https://reviews.llvm.org/D57278
llvm-svn: 352690
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D57439
llvm-svn: 352689
|
| |
|
|
|
|
|
|
|
|
|
| |
When linking library dependencies, we shouldn't need to export linked
libraries to dependents. We should be explicit about this in
target_link_libraries, otherwise other targets that depend on these such
as sanitizers get repeated (and possibly even conflicting) dependencies.
Differential Revision: https://reviews.llvm.org/D57456
llvm-svn: 352688
|
| |
|
|
|
|
|
|
|
|
|
|
| |
objc_alloc and objc_allocWithZone may throw exceptions if the
underlying method does. If we're in a @try block, then make sure we
emit an invoke instead of a call.
rdar://47610407
Differential revision: https://reviews.llvm.org/D57476
llvm-svn: 352687
|
| |
|
|
| |
llvm-svn: 352686
|
| |
|
|
|
|
|
|
|
| |
This adds instruction selection support for G_FABS in AArch64. It also updates
the existing basic FP tests, adds a selection test for G_FABS.
https://reviews.llvm.org/D57418
llvm-svn: 352684
|
| |
|
|
|
|
|
|
| |
Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D57477
llvm-svn: 352683
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
After the staack is unwound due to a thrown exxception,
`__stack_pointer` global can point to an invalid address. So
a `global.set` to restore `__stack_pointer` should be inserted right
after `catch` instruction.
But after r352598 the `global.set` instruction is inserted not right
after `catch` but after `block` - `br-on-exn` - `end_block` -
`extract_exception` sequence. This CL fixes it.
While doing that, we can actually move ReplacePhysRegs pass after
LateEHPrepare and merge EHRestoreStackPointer pass into LateEHPrepare,
and now placing `global.set` to `__stack_pointer` right after `catch` is
much easier. Otherwise it is hard to guarantee that `global.set` is
still right after `catch` and not touched with other transformations, in
which case we have to do something to hoist it.
Reviewers: dschuff
Subscribers: mgorny, sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D57421
llvm-svn: 352681
|
| |
|
|
|
|
|
|
|
|
| |
This extends the existing transform for:
add X, 0/1 --> sub X, 0/-1
...to allow the sibling subtraction fold.
This pattern could regress with the proposed change in D57401.
llvm-svn: 352680
|
| |
|
|
|
|
|
| |
As discussed/shown in D57401, we are missing a fold for
subtract of 0/1 --> add 0/-1.
llvm-svn: 352678
|
| |
|
|
|
|
|
|
|
| |
Summary:
When we are creating a ClassTemplateSpecializationDecl in ParseTypeFromDWARF(...) we are not handling the case where variadic pack is empty in the specialization. This patch handles that case and adds a test to prevent future regressions.
Differential Revision: https://reviews.llvm.org/D57363
llvm-svn: 352677
|
| |
|
|
|
|
|
| |
This API will be extracted into a new template class. This change will
make the follow-up commit easier to review.
llvm-svn: 352676
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This teaches GlobalISel to emit a RTLib call for @llvm.log2 when it encounters
it.
It updates the existing floating point tests to show that we don't fall back on
the intrinsic, and select the correct instructions. It also adds a legalizer
test for G_FLOG2.
https://reviews.llvm.org/D57357
llvm-svn: 352673
|
| |
|
|
|
|
|
| |
This is only a formal language feature in ObjC, otherwise its just an
extension. Making this change was also an ABI break.
llvm-svn: 352672
|
| |
|
|
|
|
|
|
|
|
| |
This teaches the legalizer about G_FSQRT in AArch64. Also adds a legalizer
test for G_FSQRT, a selection test for it, and updates existing floating point
tests.
https://reviews.llvm.org/D57361
llvm-svn: 352671
|
| |
|
|
|
|
|
|
|
|
|
| |
Follow-up commit to https://reviews.llvm.org/D57359. (r352668)
This adds IRTranslator support for recognising a @llvm.sqrt intrinsic and
translating it into a G_FSQRT.
https://reviews.llvm.org/D57360
llvm-svn: 352670
|
| |
|
|
|
|
|
|
|
|
| |
required.
Function __kmpc_push_target_tripcount should be emitted only if the
offloading entry is going to be emitted (for use in tgt_target...
functions). Otherwise, it should not be emitted.
llvm-svn: 352669
|
| |
|
|
|
|
|
|
|
| |
This introduces a generic instruction for computing the floating point
square root of a value.
Right now, we can't select @llvm.sqrt, so this is working towards fixing that.
llvm-svn: 352668
|
| |
|
|
|
|
|
|
|
| |
Previously we were never setting this which means it was always being
set to Default (-O2/-Os).
Differential Revision: https://reviews.llvm.org/D57422
llvm-svn: 352667
|
| |
|
|
|
|
|
|
| |
causing
assertions on some buildbots.
llvm-svn: 352666
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This builtin has the same UI as __builtin_object_size, but has the
potential to be evaluated dynamically. It is meant to be used as a
drop-in replacement for libraries that use __builtin_object_size when
a dynamic checking mode is enabled. For instance,
__builtin_object_size fails to provide any extra checking in the
following function:
void f(size_t alloc) {
char* p = malloc(alloc);
strcpy(p, "foobar"); // expands to __builtin___strcpy_chk(p, "foobar", __builtin_object_size(p, 0))
}
This is an overflow if alloc < 7, but because LLVM can't fold the
object size intrinsic statically, it folds __builtin_object_size to
-1. With __builtin_dynamic_object_size, alloc is passed through to
__builtin___strcpy_chk.
rdar://32212419
Differential revision: https://reviews.llvm.org/D56760
llvm-svn: 352665
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is meant to be used with clang's __builtin_dynamic_object_size.
When 'true' is passed to this parameter, the intrinsic has the
potential to be folded into instructions that will be evaluated
at run time. When 'false', the objectsize intrinsic behaviour is
unchanged.
rdar://32212419
Differential revision: https://reviews.llvm.org/D56761
llvm-svn: 352664
|
| |
|
|
|
|
| |
This will make follow-up changes easier to review.
llvm-svn: 352663
|
| |
|
|
| |
llvm-svn: 352662
|
| |
|
|
|
|
| |
This will make follow-up commits easier to review.
llvm-svn: 352661
|
| |
|
|
|
|
|
|
|
|
| |
This fixes the test case in PR35982 by preventing MMX instructions that read MM0-7 from being moved below EMMS/FEMMS by the post RA scheduler.
Though as discussed in bugzilla, this is not a complete fix. There is still the possibility of reordering in IR or by the pre-RA scheduler.
Differential Revision: https://reviews.llvm.org/D57298
llvm-svn: 352660
|
| |
|
|
| |
llvm-svn: 352659
|
| |
|
|
|
|
| |
This reverts commit r352654: this broke libcxx and sanitizer bots.
llvm-svn: 352658
|