| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-fprofile-generate
See PR43425:
https://bugs.llvm.org/show_bug.cgi?id=43425
When writing profile data on Windows we were opening profile file with
exclusive read/write access.
In case we are trying to write to the file from multiple processes
simultaneously, subsequent calls to CreateFileA would return
INVALID_HANDLE_VALUE.
To fix this, I changed to open without exclusive access and then take a
lock.
Patch by Michael Holman!
Differential revision: https://reviews.llvm.org/D70330
|
| |
|
|
|
|
|
|
|
|
| |
increment/decrement (PR44054)"
The asssertion that was added does not hold,
breaks on test-suite/MultiSource/Applications/SPASS/analyze.c
Will reduce the testcase and revisit.
This reverts commit 9872ea4ed1de4c49300430e4f1f4dfc110a79ab9, 870f3542d3e0d06d208442bdca6482866b59171b.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR44054)
Summary:
Implicit Conversion Sanitizer is *almost* feature complete.
There aren't *that* much unsanitized things left,
two major ones are increment/decrement (this patch) and bit fields.
As it was discussed in
[[ https://bugs.llvm.org/show_bug.cgi?id=39519 | PR39519 ]],
unlike `CompoundAssignOperator` (which is promoted internally),
or `BinaryOperator` (for which we always have promotion/demotion in AST)
or parts of `UnaryOperator` (we have promotion/demotion but only for
certain operations), for inc/dec, clang omits promotion/demotion
altogether, under as-if rule.
This is technically correct: https://rise4fun.com/Alive/zPgD
As it can be seen in `InstCombineCasts.cpp` `canEvaluateTruncated()`,
`add`/`sub`/`mul`/`and`/`or`/`xor` operators can all arbitrarily
be extended or truncated:
https://github.com/llvm/llvm-project/blob/901cd3b3f62d0c700e5d2c3f97eff97d634bec5e/llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp#L1320-L1334
But that has serious implications:
1. Since we no longer model implicit casts, do we pessimise
their AST representation and everything that uses it?
2. There is no demotion, so lossy demotion sanitizer does not trigger :]
Now, i'm not going to argue about the first problem here,
but the second one **needs** to be addressed. As it was stated
in the report, this is done intentionally, so changing
this in all modes would be considered a penalization/regression.
Which means, the sanitization-less codegen must not be altered.
It was also suggested to not change the sanitized codegen
to the one with demotion, but i quite strongly believe
that will not be the wise choice here:
1. One will need to re-engineer the check that the inc/dec was lossy
in terms of `@llvm.{u,s}{add,sub}.with.overflow` builtins
2. We will still need to compute the result we would lossily demote.
(i.e. the result of wide `add`ition/`sub`traction)
3. I suspect it would need to be done right here, in sanitization.
Which kinda defeats the point of
using `@llvm.{u,s}{add,sub}.with.overflow` builtins:
we'd have two `add`s with basically the same arguments,
one of which is used for check+error-less codepath and other one
for the error reporting. That seems worse than a single wide op+check.
4. OR, we would need to do that in the compiler-rt handler.
Which means we'll need a whole new handler.
But then what about the `CompoundAssignOperator`,
it would also be applicable for it.
So this also doesn't really seem like the right path to me.
5. At least X86 (but likely others) pessimizes all sub-`i32` operations
(due to partial register stalls), so even if we avoid promotion+demotion,
the computations will //likely// be performed in `i32` anyways.
So i'm not really seeing much benefit of
not doing the straight-forward thing.
While looking into this, i have noticed a few more LLVM middle-end
missed canonicalizations, and filed
[[ https://bugs.llvm.org/show_bug.cgi?id=44100 | PR44100 ]],
[[ https://bugs.llvm.org/show_bug.cgi?id=44102 | PR44102 ]].
Those are not specific to inc/dec, we also have them for
`CompoundAssignOperator`, and it can happen for normal arithmetics, too.
But if we take some other path in the patch, it will not be applicable
here, and we will have most likely played ourselves.
TLDR: front-end should emit canonical, easy-to-optimize yet
un-optimized code. It is middle-end's job to make it optimal.
I'm really hoping reviewers agree with my personal assessment
of the path this patch should take..
Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=44054 | PR44054 ]].
Reviewers: rjmccall, erichkeane, rsmith, vsk
Reviewed By: erichkeane
Subscribers: mehdi_amini, dexonsmith, cfe-commits, #sanitizers, llvm-commits, aaron.ballman, t.p.northover, efriedma, regehr
Tags: #llvm, #clang, #sanitizers
Differential Revision: https://reviews.llvm.org/D70539
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As mentioned in D69104, glibc changed ABI recently with the [[ https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=2f959dfe849e0646e27403f2e4091536496ac0f0| 2f959dfe ]] change.
D69104 dealt with just 32-bit ARM, but that is just one of the many affected architectures.
E.g. x86_64, i?86, riscv64, sparc 32-bit, s390 31-bit are affected too (and various others).
This patch instead of adding a long list of further architectures that wouldn't be checked ever next to arm 32-bit changes the structures to match the 2.31 layout and performs the checking on Linux for ipc_perm mode position/size only on non-Linux or on Linux with glibc 2.31 or later. I think this matches what is done for aarch64 already.
If needed, we could list architectures that haven't changed ABI (e.g. powerpc), so that they would be checked even with older glibcs. AFAIK sanitizers don't actually use ipc_perm.mode and
so all they care about is the size and alignment of the whole structure.
Note, s390 31-bit and arm 32-bit big-endian changed ABI even further, there will now be shmctl with old symbol version and shmctl@@GLIBC_2.31 which will be incompatible. I'm afraid this isn't really solvable unless the sanitizer libraries are symbol versioned and use matching symbol versions to glibc symbols for stuff they intercept, plus use dlvsym.
This patch doesn't try to address that.
Patch by Jakub Jelinek.
Reviewers: kcc, eugenis, dvyukov
Reviewed By: eugenis
Subscribers: jyknight, kristof.beyls, fedor.sergeev, simoncook, PkmX, s.egerton, steven.zhang, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D70662
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Implements __fixtfti builtin for PowerPC. This builtin converts a
long double (IBM double-double) to a signed int128. The conversion relies on
the unsigned conversion of the absolute value of the long double.
Tests included for both positive and negative long doubles.
Patch By: Baptiste Saleil
Differential Revision: https://reviews.llvm.org/D69730
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When platforms use their own `LIKELY()` definitions, it can be quite
troublesome to ensure they don't conflict with the GWP-ASan internal
definitions. Just force the GWP_ASAN_ prefix to help this issue.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: #sanitizers, llvm-commits, cferris, pcc
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D70683
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
cferris@ found an issue where calling `releaseToOS` prior to any other
heap operation would lead to a crash, due to the allocator not being
properly initialized (it was discovered via `mallopt`).
The fix is to call `initThreadMaybe` prior to calling `releaseToOS` for
the Primary.
Add a test that crashes prior to fix.
Reviewers: hctim, cferris, pcc, eugenis
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D70552
|
| |
|
|
|
|
|
|
| |
On Darwin, part of the profile runtime is included in the builtin
library. f35032e changed the location of InstrProfData.inc but the
builtin build for Darwin hasn't been updated to include the new
path which causes a breakage when building for Darwin. This change
addresses this breakage.
|
| |
|
|
|
|
|
|
|
|
|
| |
This header fragment is useful on its own for any consumer that wants
to use custom instruction profile runtime with the LLVM instrumentation.
The concrete use case is in Fuchsia's kernel where we want to use
instruction profile instrumentation, but we cannot use the compiler-rt
runtime because it's not designed for use in the kernel environment.
This change allows installing this header as part of compiler-rt.
Differential Revision: https://reviews.llvm.org/D64532
|
| |
|
|
|
| |
This reverts commit f11bc1776fd2815b60e0b1ed97be00b517348162 since it's
failing to build on some bots.
|
| |
|
|
|
|
|
|
|
|
|
| |
This header fragment is useful on its own for any consumer that wants
to use custom instruction profile runtime with the LLVM instrumentation.
The concrete use case is in Fuchsia's kernel where we want to use
instruction profile instrumentation, but we cannot use the compiler-rt
runtime because it's not designed for use in the kernel environment.
This change allows installing this header as part of compiler-rt.
Differential Revision: https://reviews.llvm.org/D64532
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Allows to use rr with asan
Fixes PR41095
Reviewers: eugenis
Subscribers: jfb, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D70581
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit moves the `DiscardOutput` function in FuzzerIO to
FuzzerUtil, so fuchsia can have its own specialized version.
In fuchsia, accessing `/dev/null` is not supported, and there's nothing
similar to a file that discards everything that is written to it. The
way of doing something similar in fuchsia is by using `fdio_null_create`
and binding that to a file descriptor with `fdio_bind_to_fd`.
This change should fix one of the issues with the `-close_fd_mask` flag
in libfuzzer, in which closing stdout was not working due to
`fopen("/dev/null", "w")` returning `NULL`.
Reviewers: kcc, aarongreen
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69593
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit fixes part of the issues with stack unwinding in fuchsia for
arm64 and x86_64. It consists of multiple fixes:
(1) The cfa_offset calculation was wrong, instead of pointing to the
previous stack pointer, it was pointing to the current one. It worked in
most of the cases because the crashing functions already had a
prologue and had their cfa information relative to another register. The
fix consists on adding a constant that can be used to calculate the
crashing function's stack pointer, and base all the cfi information
relative to that offset.
(2) (arm64) Due to errors with the syntax for the dwarf information, most
of the `OP_NUM` macros were not working. The problem was that they were
referred to as `r##NUM` (like `r14`), when it should have been `x##num`
(like `x14`), or even without the x.
(3) (arm64) The link register was being considered a part of the main
registers (`r30`), when in the real struct it has its own field. Given
that the link register is in the same spot in the struct as r[30] would be,
and that C++ doesn't care about anything, the calculation was still correct.
(4) (x86_64) The stack doesn't need to be aligned to 16 bytes when we
jump to the trampoline function, but it needs to be before performing
call instructions. Encoding that logic in cfi information was tricky, so
we decided to make the cfa information relative to `rbp` and align `rsp`.
Note that this could have been done using another register directly,
but it seems cleaner to make a new fake stack frame.
There are some other minor changes like adding a `brk 1` instruction in
arm64 to make sure that we never return to the crash trampoline (similar to
what we do in x86_64).
Sadly this commit does not fix unwinding for all use cases for arm64.
Crashing functions that do not add information related to the return column in
their cfi information will fail to unwind due to a bug in libunwinder.
Reviewers: mcgrathr, jakehehrlich, phosek, kcc, aarongreen
Subscribers: aprantl, kristof.beyls, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69579
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit fixes the check in the return value from the `DuplicateFile`
function, which returns a new file descriptor. `DuplicateFile` can
return 0 if that file descriptor is available (for example, if stdin has
already been closed).
In particular, this could cause a bug with the `-close_fd_mask` flag in
some platforms: just call the fuzzer with stdin closed and the
`-close_fd_mask=2` flag, and stderr will not be muted.
Example fuzzer:
```
extern "C" int LLVMFuzzerTestOneInput(const uint8_t* Data, size_t Size) {
fprintf(stderr, "STDERR\n");
fprintf(stdout, "STDOUT\n");
return 0;
}
```
Invocation (muting both stderr and stdout):
```
./test -close_fd_mask=3 -runs=1 0<&-
INFO: Seed: 1155116940
INFO: Loaded 1 modules (1 inline 8-bit counters): 1 [0x48b020, 0x48b021),
INFO: Loaded 1 PC tables (1 PCs): 1 [0x478dc8,0x478dd8),
INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes
STDERR
INFO: A corpus is not provided, starting from an empty corpus
STDERR
Done 2 runs in 0 second(s)
```
Reviewers: mcgrathr, jakehehrlich, phosek, kcc, aarongreen
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D68775
|
| |
|
|
| |
rdar://57365733
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A few small improvements and optimizations:
- when refilling the free list, push back the last batch and return
the front one: this allows to keep the allocations towards the front
of the region;
- instead of using 48 entries in the shuffle array, use a multiple of
`MaxNumCached`;
- make the maximum number of batches to create on refil a constant;
ultimately it should be configurable, but that's for later;
- `initCache` doesn't need to zero out the cache, it's already done.
- it turns out that when using `||` or `&&`, the compiler is adamant
on adding a short circuit for every part of the expression. Which
ends up making somewhat annoying asm with lots of test and
conditional jump. I am changing that to bitwise `|` or `&` in two
place so that the generated code looks better. Added comments since
it might feel weird to people.
This yields to some small performance gains overall, nothing drastic
though.
Reviewers: hctim, morehouse, cferris, eugenis
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D70452
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Darwin lazily saves the AVX512 context on first use [1]: instead of checking
that it already does to figure out if the OS supports AVX512, trust that
the kernel will do the right thing and always assume the context save
support is available.
[1] https://github.com/apple/darwin-xnu/blob/xnu-4903.221.2/osfmk/i386/fpu.c#L174
Reviewers: ab, RKSimon, craig.topper
Reviewed By: craig.topper
Subscribers: dberris, JDevlieghere, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D70454
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
the allocator.
When we're not building libc's allocator, just use a regular TLS variable. This
lets the unit tests pass on Android devices whose libc uses Scudo. Otherwise
libc's copy of Scudo and the unit tests' copy will both try to use the same
TLS slot, in likely incompatible ways.
This requires using ELF TLS, so start passing -fno-emulated-tls when building
the library and the unit tests on Android.
Differential Revision: https://reviews.llvm.org/D70472
|
| |
|
|
|
|
| |
This lets the test build with C++17.
Differential Revision: https://reviews.llvm.org/D70471
|
| |
|
|
|
| |
This '#ifdef's out two functions which are unused on Windows, to prevent
-Wunused-function warnings.
|
| |
|
|
|
|
| |
Continuous mode is not yet supported on Fuchsia/Windows, however an
error should not be reported unless the user attempted to actually
enable continuous mode.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The sanitizer symbolizers support printing the function offset
(difference between pc and function start) of a stackframe using the
`%q` format specifier.
Unfortunately this didn't actually work because neither the atos
or dladdr symbolizer set the `AddressInfo::function_offset` field.
This patch teaches both symbolizers to try to compute the function
offset. In the case of the atos symbolizer, atos might not report the
function offset (e.g. it reports a source location instead) so in this
case it fallsback to using `dladdr()` to compute the function offset.
Two test cases are included.
rdar://problem/56695185
Reviewers: kubamracek, yln
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69549
|
| |
|
|
|
|
|
|
| |
It broke the build with MSVC:
fp_mode.c(20): error C2065: '__asm__': undeclared identifier
> Differential Revision: https://reviews.llvm.org/D69870
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make it possible to use online profile merging ("%m" mode) with
continuous sync ("%c" mode).
To implement this, the merged profile is locked in the runtime
initialization step and either a) filled out for the first time or b)
checked for compatibility. Then, the profile can simply be mmap()'d with
MAP_SHARED set. With the mmap() in place, counter updates from every
process which uses an image are mapped onto the same set of physical
pages assigned by the filesystem cache. After the mmap() is set up, the
profile is unlocked.
Differential Revision: https://reviews.llvm.org/D69586
|
| |
|
|
|
|
|
|
|
|
| |
compiler-rt's getAMDProcessorTypeAndSubtype.
This is the CPUID model used on Ryzen 3000 series (Zen 2/Matisse) CPUs.
Patch by Alex James
Differential Revision: https://reviews.llvm.org/D70279
|
| |
|
|
| |
Differential Revision: https://reviews.llvm.org/D69870
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Bump default value for `-miphoneos-version-min=x` to 9.0 (from 8.0).
TSan tests that use thread local storage `__thread` (e.g., tls_race.cpp)
are failing to link for the iOS simulator (arch=x86_64 and
-miphoneos-version-min=8.0) on internal/master (will be submitted to
Glacier train):
```
ld: targeted OS version does not support use of thread local variables in _main for architecture x86_64
```
iOS 9.0 was released 2015.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Bump default value for `SANITIZER_MIN_OSX_VERSION` to 10.10 (from 10.9).
TSan does not work on macOS 10.9 and a nice error message is preferable
to an "unreferenced symbol" error when loading the TSan runtime.
We could try to only bump the deployment target for TSan, but we would
have to invest into adding support for this to our CMake build and it
does not seem worth it. macOS 10.10 was released in 2014.
rdar://31335781
|
| |
|
|
|
|
| |
coverage-fork.cpp uses `fork()` which requires additional permissions
in the iOS simulator sandbox. We cannot use `sandbox-exec` to grant
these permissions since this is a Posix (not Darwin) test.
|
| |
|
|
|
|
|
|
| |
This is a patch to support D66328, which was reverted until this lands.
Enable a compiler-rt test that used to fail previously with D66328.
Differential Revision: https://reviews.llvm.org/D67283
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
`SCUDO_DEBUG` was not enabled for unit tests, meaning the `DCHECK`s
were never tripped. While turning this on, I discovered that a few
of those not-exercised checks were actually wrong. This CL addresses
those incorrect checks.
Not that to work in tests `CHECK_IMPL` has to explicitely use the
`scudo` namespace. Also changes a C cast to a C++ cast.
Reviewers: hctim, pcc, cferris, eugenis, vitalybuka
Subscribers: mgorny, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D70276
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously it wasn't obvious what the default value of various sanitizer
options were. A very close approximation of the "default values" for the
options are the current value of the options at the time of printing the
help output.
In the case that no other options are provided then the current values
are the default values (apart from `help`).
```
ASAN_OPTIONS=help=1 ./program
```
This patch causes the current option values to be printed when the
`help` output is enabled. The original intention for this patch was to append
`(Default: <value>)` to an option's help text. However because this
is technically wrong (and misleading) I've opted to append
`(Current Value: <value>)` instead.
When trying to implement a way of displaying the default value of the
options I tried another solution where the default value used in `*.inc` files
were used to create compile time strings that where used when printing
the help output. This solution was not satisfactory for several reasons:
* Stringifying the default values with the preprocessor did not work very
well in several cases. Some options contain boolean operators which no
amount of macro expansion can get rid of.
* It was much more invasive than this patch. Every sanitizer had to be changed.
* The settings of `__<sanitizer>_default_options()` are ignored.
For those reasons I opted for the solution in this patch.
rdar://problem/42567204
Reviewers: kubamracek, yln, kcc, dvyukov, vitalybuka, cryptoad, eugenis, samsonov
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69546
|
| |
|
|
|
|
|
|
|
|
|
| |
Split out the logic to get the size of a merged profile and to do a
compatibility check. This can be shared with both the continuous+merging
mode implementation, as well as the runtime-allocated counters
implementation planned for Fuchsia.
Lifted out of D69586.
Differential Revision: https://reviews.llvm.org/D70135
|
| |
|
|
|
|
|
|
| |
A few years back a similar change was made for getenv since neither function is supported on the PS4 platform.
Recently, commit d889d1e added a call to setenv in compiler-rt which was causing linking errors because the symbol was not found. This fixes that issue by putting in a shim similar to how we previously dealt with the lack of getenv.
Differential Revision: https://reviews.llvm.org/D70033
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch fixes two problems with the crtbegin.c as written:
1. In do_init, register_frame_info is not guarded by a #define, but in
do_fini, deregister_frame_info is guarded by #ifndef
CRT_HAS_INITFINI_ARRAY. Thus when CRT_HAS_INITFINI_ARRAY is not
defined, frames are registered but then never deregistered.
The frame registry mechanism builds a linked-list from the .so's
static variable do_init.object, and when the .so is unloaded, this
memory becomes invalid and should be deregistered.
Further, libgcc's crtbegin treats the frame registry as independent
from the initfini array mechanism.
This patch fixes this by adding a new #define,
"EH_USE_FRAME_INFO_REGISTRY", which is set by the cmake option
COMPILER_RT_CRT_USE_EH_FRAME_REGISTRY Currently, do_init calls
register_frame_info, and then calls the binary's constructors. This
allows constructors to safely use libunwind. However, do_fini calls
deregister_frame_info and then calls the binary's destructors. This
prevents destructors from safely using libunwind.
This patch also switches that ordering, so that destructors can safely
use libunwind. As it happens, this is a fairly common scenario for
thread sanitizer.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Bionic was modified to have all function names consistent. Modify the code and get rid of the special case for bionic since it's no longer needed.
Reviewers: cryptoad
Reviewed By: cryptoad
Subscribers: srhines, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D70031
|
| |
|
|
| |
This reverts commit d6be9273c6035c07b25dd1494f76cd61d523b878.
|
| |
|
|
|
|
|
|
|
|
|
| |
__fixunstfti converts a long double (IBM double-double) to an unsigned 128 bit
integer. This patch enables it to handle a previously unhandled case in which
a negative low double may impact the result of the conversion.
Collaborated with @masoud.ataei and @renenkel.
Patch By: Baptiste Saleil
Differential Revision: https://reviews.llvm.org/D69193
|
| |
|
|
|
|
| |
This reverts commit bdeb2724f0aa9c518f94d998d24d8620a1e88727.
(Reverting 03b84e4f6d0, so this must come out as well)
|
| |
|
|
|
|
|
| |
Fallout from:
[clang] Report sanitizer blacklist as a dependency in cc1
Default blacklists are now passed via -fsanitize-system-blacklist from driver to cc1.
|
| |
|
|
|
|
|
| |
https://bugs.llvm.org/show_bug.cgi?id=43722
GWP-ASan didn't include SANITIZER_COMMON_CFLAGS, and thus would produce
LLVM bitcode files, when compiler-rt is generally built without LTO.
|
| |
|
|
|
|
|
| |
This allows crtbegin and crtend to be built, allowing RISC-V
to no longer rely on implementations from libgcc.
Differential revision: https://reviews.llvm.org/D68393
|
| |
|
|
|
|
|
|
|
|
| |
is not built
D69405 causes failure if running LIT when the compiler was built without lld.
Patch by Anh Tuyen Tran (anhtuyen)
Differential Revision: https://reviews.llvm.org/D69685
|
| |
|
|
| |
Fixes warning: unused variable 'XXX' [-Wunused-const-variable]
|
| |
|
|
| |
'unsigned long long' [-Wformat]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was an experiment made possible by a non-standard feature of the
Android dynamic loader.
It required introducing a flag to tell the compiler which ABI was being
targeted.
This flag is no longer needed, since the generated code now works for
both ABI's.
We leave that flag untouched for backwards compatibility. This also
means that if we need to distinguish between targeted ABI's again
we can do that without disturbing any existing workflows.
We leave a comment in the source code and mention in the help text to
explain this for any confused person reading the code in the future.
Patch by Matthew Malcomson
Differential Revision: https://reviews.llvm.org/D69574
|
| |
|
|
| |
Fixes build with GCC8.
|
| |
|
|
| |
Fixes build of test.
|
