The globals are better expressed as members of the Symbolizer, and all
functions operating on it should be methods instead.
Also using the standard idiom of wrapping the main code in
`if __name__ == '__main__'`.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D125032
Since D97044, libc++ implements <stdatomic.h>, which is not compatible
with the <atomic> header in C++03 mode. To fix the tests, avoid using
<stdatomic.h> at all, since it is not strictly required.
rdar://92867529
Differential Revision: https://reviews.llvm.org/D125118
This changes the ELFNix platform Orc runtime to use, when available,
the __unw_add_dynamic_eh_frame_section interface provided by libunwind
for registering .eh_frame sections loaded by JITLink. When libunwind
is not being used for unwinding, the ELFNix platform detects this and
defaults to the __register_frame interface provided by libgcc_s.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D114961
The mechanism behind "check-all" is recording params of add_lit_testsuite()
calls in global variables LLVM_LIT_*, and then creating an extra suite with
their union at the end.
This avoids composing the check-* targets directly, which doesn't work well.
We generalize this by allowing multiple families of variables LLVM_{name}_LIT_*:
umbrella_lit_testsuite_begin(check-foo)
... test suites here will be added to LLVM_FOO_LIT_* variables ...
umbrella_lit_testsuite_end(check-foo)
(This also moves some implementation muck out of {llvm,clang}/CMakeLists.txt
This patch also changes check-clang-tools to use be an umbrella test target,
which means the clangd and clang-pseudo tests are included in it, along with the
the other testsuites that already are (like check-clang-extra-clang-tidy).
Differential Revision: https://reviews.llvm.org/D121838
The globals are better expressed as members of the Symbolizer, and all
functions operating on it should be methods instead.
Also using the standard idiom of wrapping the main code in
`if __name__ == '__main__'`.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D125032
D116208 (commit 1298273e82) added FP_XSTATE_MAGIC1.
However, when building with glibc < 2.16 for backward-dependency
compatibility, it is not defined - and the build breaks.
Note: The define comes from Linux's asm/sigcontext.h but the
file uses signal.h which includes glibc's bits/sigcontext.h - which
is synced from the kernel's file but lags behind.
Solution: For backward compatility with ancient systems, define
FP_XSTATE_MAGIC1 if undefined.
//For the old systems, we were building with Linux kernel 3.19 but to support really old glibc systems, we build with a sysroot of glibc 2.12. While our kernel (and the users' kernels) have FP_XSTATE_MAGIC1, glibc 2.12 is too old. – With this patch, building the sanitizer libs works again. This showed up for us today as GCC mainline/13 has now synced the sanitizer libs.//
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D124927
This patch switches the PGO implementation on AIX from using the runtime
registration-based section tracking to the __start_SECNAME/__stop_SECNAME
based. In order to enable the recognition of __start_SECNAME/__stop_SECNAME
symbols in the AIX linker, the -bdbg:namedsects:ss needs to be used.
Reviewed By: jsji, MaskRay, davidxl
Differential Revision: https://reviews.llvm.org/D124857
D123200 did not include the generic sources, which means that only the
AVR-specific sources were compiled. With this change, generic sources
are included as expected.
Tested with the following commands:
cmake -G Ninja -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE=avr -DCOMPILER_RT_BAREMETAL_BUILD=1 -DCMAKE_C_COMPILER=clang-14 -DCMAKE_C_FLAGS="--target=avr -mmcu=avr5 -nostdlibinc -mdouble=64" ../path/to/builtins
ninja
Differential Revision: https://reviews.llvm.org/D124969
Previously the default was long, which is 32-bit on AVR. But avr-gcc
expects a smaller value: it reads the return value from r24.
This is actually a regression from https://reviews.llvm.org/D98205.
Before D98205, the return value was an enum (which was 2 bytes in size)
which was compatible with the 1-byte return value that avr-gcc was
expecting. But long is 4 bytes and thus places the significant return
value in a different register.
Differential Revision: https://reviews.llvm.org/D124939
Fixes:
tsan/tsan_shadow.h:93:32: warning: enumerated and non-enumerated type in conditional expression [-Wextra]
tsan/tsan_shadow.h:94:44: warning: enumerated and non-enumerated type in conditional expression [-Wextra]
Differential Revision: https://reviews.llvm.org/D124828
After cd0a5889d7, unittest would run in shard mode where many tests
share a single process. Need to clear some global state to make the test
results stable.
Reviewed By: thetruestblue, rsundahl
Differential Revision: https://reviews.llvm.org/D124591
First check for clang::fallthrough attribute that resolves:
sanitizer_stack_store.cpp:258:7: error: use of the 'fallthrough'
attribute is a C++17 extension [-Werror,-Wc++17-attribute-extensions]
Use the pragma only when __clang__ is defined.
Fixes:
sanitizer_common_libcdep.cpp:101: warning: ignoring ‘#pragma clang diagnostic’ [-Wunknown-pragmas]
Differential Revision: https://reviews.llvm.org/D124829
Fixes:
sanitizer_stack_store.cpp:257:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
when being built with GCC.
Differential Revision: https://reviews.llvm.org/D124832
These "new" syscalls have been added in 2.6.16, more than 16 years ago.
Surely that's enough time to migrate. Glibc 2.33 is using them on both
i386 and x86_64. Android has an selinux filter to block the legacy
syscalls in the apps.
Differential Revision: https://reviews.llvm.org/D124212
Profile library are written by standard libraries or POSIX calls depend on target support, so there is no porting effort for the target, we could enable that for both RV32 and RV64, verified on the RV64 platform.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D124599
By default -fsanitize=address already compiles with this check, why not use it.
For compatibly it can be disabled with env ASAN_OPTIONS=detect_stack_use_after_return=0.
Reviewed By: eugenis, kda, #sanitizers, hans
Differential Revision: https://reviews.llvm.org/D124057
The current darwin abort_on_error test specifically tests for a division
by zero undefined behavior. However arm does not trap by default for this
behavior. x86 signals the abort, which is why the test passes on x86.
This patch updates the test to test for a case where the ubsan runtime
specifically calls Die() to trigger an abort by default.
rdar://92108564
Differential Revision: https://reviews.llvm.org/D124480
An application can use the mere fact of epoll_wait returning an fd
as synchronization with the write on the fd that triggered the notification.
This pattern come up in an internal networking server (b/229276331).
If an fd is added to epoll, setup a link from the fd to the epoll fd
and use it for synchronization as well.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D124518
Temporarily revert the option to fix
https://bugs.chromium.org/p/chromium/issues/detail?id=1319387
This reverts option default and documentation of the commit. Test
changes are not being reverted as they are improvement and break
reliance on option defaults.
Additional memory usage is a problem on mobile devices with low memory.
Even heavy thread desktop programs may need some FakeStack tunning.
This reverts commit 4b4437c084.
This avoids the need for string-ification and lets CMake deduplicate
potentially duplicate flags.
Differential Revision: https://reviews.llvm.org/D122750
Apply this in add_compiler_rt_runtime instead of manually adding it
to the individual projects. This applies the option on more
parts of compiler-rt than before, but should ideally not make any
difference assuming the other runtimes that lacked the option
also were C11 compatible.
Not marking this as required, to match the existing behaviour (where
`-std=c11` was added only if supported by the compiler).
This was suggested during the review of D110005.
Differential Revision: https://reviews.llvm.org/D124343
from compiler-rt/lib/tsan
[NFC] As part of using inclusive language within the llvm project, this
patch rewords comments to remove sanity check and sanity test.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D124390
Avoid repeating CMake checks across runtimes by unifying names of
variables used for results to leverage CMake caching.
Differential Revision: https://reviews.llvm.org/D110005
Fix mismatched-new-delete in asan test unaligned_loads_and_stores.cpp
Reviewed By: vitalybuka, MaskRay
Differential Revision: https://reviews.llvm.org/D124268
This reverts commit 3469cb14e2.
Relanding the patch on behalf of Byoungchan Lee.
The original patch (8a3afc6da5) was
reverted because it appeared to be landed without the approval
of an Apple engineer.
After internal discussion we're happy for this to land and I've
formally approved the patch in phabricator
(https://reviews.llvm.org/D119174).
rdar://92134140
This reverts commit 8a3afc6da5.
The commit being was landed without review from any Apple engineers
which is problematic because the patch only affects Apple platforms.
rdar://92134140
By default -fsanitize=address already compiles with this check,
why not use it.
For compatibly it can be disabled with env ASAN_OPTIONS=detect_stack_use_after_return=0.
Reviewed By: eugenis, kda, #sanitizers, hans
Differential Revision: https://reviews.llvm.org/D124057
These "new" syscalls have been added in 2.6.16, more than 16 years ago.
Surely that's enough time to migrate. Glibc 2.33 is using them on both
i386 and x86_64. Android has an selinux filter to block the legacy
syscalls in the apps.
Differential Revision: https://reviews.llvm.org/D124212
Fixes llvm-project/compiler-rt/test/asan/TestCases/null_deref.cpp on
macOS/aarch64.
The bp (base pointer) variable was being loaded from register LR and
not FP on aarch64 (except for this narrow case):
defined(__IPHONE_8_0) && __IPHONE_OS_VERSION_MAX_ALLOWED >= __IPHONE_8_0
Without a valid bp from the FP register, it is not possible to traverse
previous frames for a complete stack trace. The rationale for fetching
the LR as the bp for all cases except above is not clear but since the
FP register is the canonical register for use as the frame pointer, this
commit removes the restriction above for unconditional use all aarch64.
rdar://91587039
Differential Revision: https://reviews.llvm.org/D124140
On systems where the kernel supports the PR_SCHED_CORE
interface, but there is no SMT, the prctl call will set
errno to ENODEV, which currently causes the test to fail.
Fix by accepting ENODEV in addition to EINVAL.
InstrProfilingPlatformLinux.c already provides these symbols. Linker order
saved us from noticing before.
Reviewed By: mcgrathr
Differential Revision: https://reviews.llvm.org/D124136
This patch is the reland of a8e5ce76b4,
which includes additional SDK version checks to ensure that
XCode's headers support arm64 builds.
Differential Revision: https://reviews.llvm.org/D119174
C89 had a questionable feature where the compiler would implicitly
declare a function that the user called but was never previously
declared. The resulting function would be globally declared as
extern int func(); -- a function without a prototype which accepts zero
or more arguments.
C99 removed support for this questionable feature due to severe
security concerns. However, there was no deprecation period; C89 had
the feature, C99 didn't. So Clang (and GCC) both supported the
functionality as an extension in C99 and later modes.
C2x no longer supports that function signature as it now requires all
functions to have a prototype, and given the known security issues with
the feature, continuing to support it as an extension is not tenable.
This patch changes the diagnostic behavior for the
-Wimplicit-function-declaration warning group depending on the language
mode in effect. We continue to warn by default in C89 mode (due to the
feature being dangerous to use). However, because this feature will not
be supported in C2x mode, we've diagnosed it as being invalid for so
long, the security concerns with the feature, and the trivial
workaround for users (declare the function), we now default the
extension warning to an error in C99-C17 mode. This still gives users
an easy workaround if they are extensively using the extension in those
modes (they can disable the warning or use -Wno-error to downgrade the
error), but the new diagnostic makes it more clear that this feature is
not supported and should be avoided. In C2x mode, we no longer allow an
implicit function to be defined and treat the situation the same as any
other lookup failure.
Differential Revision: https://reviews.llvm.org/D122983
Like D118875, but for ubsan, asan, etc.
With this, I can successfully run:
bin/clang++ -target x86_64-apple-ios14.0-macabi foo.cc \
-isysroot $(xcrun -show-sdk-path) -fsanitize=undefined
with a locally built libclang_rt.ubsan_osx_dynamic.dylib.
Differential Revision: https://reviews.llvm.org/D124059
Makes
bin/llvm-lit \
projects/compiler-rt/test/profile/Profile-arm64/instrprof-darwin-dead-strip.c
pass on my machine.
Without this change, ld64 complains that the bitcode was generated by LLVM 15
while the reader is 13.1 -- the version of Xcode on my machine. Looks like the
DYLD_LIBRARY_PATH technique isn't working.
-lto_library was added back in ld64-136, which was in Xcode 4.6, which was
released over 10 years ago. So relying on it should be safe by now.
Differential Revision: https://reviews.llvm.org/D124018
1. Add correct pc, sp and bp for FreeBSD.
2. Since there's no personality.h header on FreeBSD, move SANITIZER_PPC64V2
case below FREEBSD case.
3. __ppc_get_timebase_freq() is glibc-specific. Add a shim for FreeBSD that
does the same.
Looks like when the VE support was added it was added a few lines below where it should have been.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D123439
Current check assumes iOS as the only Apple devices running arm64.
```#if SANITIZER_MAC && !(defined(__arm64__) && SANITIZER_IOS)```
Stops Apple Silicon from being flagged as requiring unique RTTI.
This introduced unexpected behavior within the sanitizer.
rdar://91446703
Differential Revision: https://reviews.llvm.org/D123736
Usually when we generated stacktraces the process is in error state, so
running hooks may crash the process and prevent meaningfull error report.
Symbolizer, unwinder and pthread are potential source of mallocs.
https://b.corp.google.com/issues/228110771
Reviewed By: kda
Differential Revision: https://reviews.llvm.org/D123566
This piece of code tries to implement the semantics "cross compile?" to
determine CFLAGS used for test binary compilation.
```
if(ANDROID OR ${arch} MATCHES "arm|aarch64|riscv32|riscv64")
```
Since Apple Silicon, macOS runs on arm64e, so we take the wrong branch
when compiling and running tests locally "on the host" on an AS machine.
Furthermore, for Apple code, we use the separate
`get_test_cflags_for_apple_platform` function to determine these test
compiliation flags and `get_test_cc_for_arch` is only ever used in the
"compile & run on host" case, so we can short-curcuit the "cross
compile?" check here.
rdar://91446703
Differential Revision: https://reviews.llvm.org/D123633
Usually when we generated stacktraces the process is in error state, so
running hooks may crash the process and prevent meaningfull error report.
Symbolizer, unwinder and pthread are potential source of mallocs.
https://b.corp.google.com/issues/228110771
Reviewed By: kda
Differential Revision: https://reviews.llvm.org/D123566
ld64 implicitly ad-hoc code-signs as of Xcode 12, and `strip` and friends know
how keep this special ad-hoc signature valid.
So this should have no effective behavior change, except that you can now strip
libclang_rt.asan_osx_dynamic.dylib and it'll still have a valid ad-hoc
signature, instead of strip printing "warning: changes being made to the file
will invalidate the code signature in:" and making the ad-hoc code signature
invalid.
Differential Revision: https://reviews.llvm.org/D123475
This reverts commit 63f2d1f4d4.
I don't quite understand why, but this causes a linker error for
me and a number of buildbots:
/home/npopov/repos/llvm-project/compiler-rt/lib/ubsan/../sanitizer_common/sanitizer_stacktrace.h:130: error: undefined reference to '__sanitizer::BufferedStackTrace::UnwindImpl(unsigned long, unsigned long, void*, bool, unsigned int)'
ubsan_GetStackTrace (from 52b751088b) called by
~ScopeReport leaves top/bottom zeroes in the
`!WillUseFastUnwind(request_fast_unwind)` code path.
When BufferedStackTrace::Unwind falls back to UnwindFast,
`if (stack_top < 4096) return;` will return early, leaving just one frame in the stack trace.
Fix this by always initializing top/bottom like 261d6e05d5.
Reviewed By: eugenis, yln
Differential Revision: https://reviews.llvm.org/D123562
Tested on an example callstack with misplaced binaries from Android.
Tested Regex against callstack without Build ID to confirm it still works.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D123437
This keeps the test behavior unchanged when CLANG_DEFAULT_PIE_ON_LINUX switches
to ON by default.
Note: current clang --target=mips64el-linux-gnu -fpie -pie -fuse-ld=lld
does not link with C++ exceptions, using -pie would lead to
```
ld.lld: error: cannot preempt symbol: DW.ref.__gxx_personality_v0
...
ld.lld: error: relocation R_MIPS_64 cannot be used against local symbol; recompile with -fPIC
...
```
when linking `ScudoUnitTests`: https://lab.llvm.org/buildbot/#/builders/169/builds/7311/steps/18/logs/stdio
According to the RFC [0], this review contains the compiler-rt parts of large integer divison for _BitInt.
It adds the functions
```
/// Computes the unsigned division of a / b for two large integers
/// composed of n significant words.
/// Writes the quotient to quo and the remainder to rem.
///
/// \param quo The quotient represented by n words. Must be non-null.
/// \param rem The remainder represented by n words. Must be non-null.
/// \param a The dividend represented by n + 1 words. Must be non-null.
/// \param b The divisor represented by n words. Must be non-null.
/// \note The word order is in host endianness.
/// \note Might modify a and b.
/// \note The storage of 'a' needs to hold n + 1 elements because some
/// implementations need extra scratch space in the most significant word.
/// The value of that word is ignored.
COMPILER_RT_ABI void __udivmodei5(su_int *quo, su_int *rem, su_int *a,
su_int *b, unsigned int n);
/// Computes the signed division of a / b.
/// See __udivmodei5 for details.
COMPILER_RT_ABI void __divmodei5(su_int *quo, su_int *rem, su_int *a, su_int *b,
unsigned int words);
```
into builtins.
In addition it introduces a new "bitint" library containing only those new functions,
which is meant as a way to provide those when using libgcc as runtime.
[0] https://discourse.llvm.org/t/rfc-add-support-for-division-of-large-bitint-builtins-selectiondag-globalisel-clang/60329
Differential Revision: https://reviews.llvm.org/D120327
All platforms return the main executable as the first dl_phdr_info.
FreeBSD, NetBSD, Solaris, and Linux-musl place the executable name
in the dlpi_name field of this entry. It appears that only Linux-glibc
uses the empty string.
To make this work generically on all platforms, unconditionally
skip the first object (like is currently done for FreeBSD and NetBSD).
This fixes first DSO detection on Linux-musl. It also would likely
fix detection on Solaris/Illumos if it were to gain PIE support
(since dlpi_addr would not be NULL).
Additionally, only skip the Linux VDSO on linux.
Finally, use the empty string as the "seen first dl_phdr_info"
marker rather than (char *)-1. If there was no other object, we
would try to dereference it for a string comparison.
Reviewed By: MaskRay, vitalybuka
Differential Revision: https://reviews.llvm.org/D119515
Compiler-rt cross-compile for ARMv5 fails because D99282 made it an error if DMB
is used for any pre-ARMv6 targets. More specifically, the "#error only supported
on ARMv6+" added in D99282 will cause compilation to fail when any source file
which includes assembly.h are compiled for pre-ARMv6 targets. Since the only
place where DMB is used is syn-ops.h (which is only included by
arm/sync_fetch_and_* and these files are excluded from being built for older
targets), this patch moves the definition there to avoid the issues described
above.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D123105
The previous check for interceptors used `pthread_create()` which is not
available on DriverKit. We need an intercepted symbol that satisfies
the following constraints:
- Symbol is available in DriverKit
- Symbol is provided by simulator runtime dylibs (`dlsym()` fails to
look up host-provided symbols)
`puts()` satisfies all of the above constraints.
rdar://87895539
Reviewed By: yln
Differential Revision: https://reviews.llvm.org/D123245
This is useful when building a complete toolchain to ensure that CRT
is built after builtins but before the rest of the compiler-rt.
Differential Revision: https://reviews.llvm.org/D120682
This is useful when building a complete toolchain to ensure that CRT
is built after builtins but before the rest of the compiler-rt.
Differential Revision: https://reviews.llvm.org/D120682
Currently LoadedModule provides max_executable_address.
Replace it with just max_address.
It's only used for printing for human inspection and since
modules are non-overlapping, max_address is as good as max_executable_address
for matching addresses/PCs against modules (I assume it's used for that).
On the hand, max_address is more general and can used to match e.g. data addresses.
I want to use it for that purpose in future changes.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D122906
Update the hardware CRC32 logic in scudo to support using `-mcrc32`
instead of `-msse4.2`. The CRC32 intrinsics use the former flag
in the newer compiler versions, e.g. in clang since 12fa608af4.
With these versions of clang, passing `-msse4.2` is insufficient
to enable the instructions and causes build failures when `-march` does
not enable CRC32 implicitly:
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/scudo_crc32.cpp:20:10: error: always_inline function '_mm_crc32_u32' requires target feature 'crc32', but would be inlined into function 'computeHardwareCRC32' that is compiled without support for 'crc32'
return CRC32_INTRINSIC(Crc, Data);
^
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/scudo_crc32.h:27:27: note: expanded from macro 'CRC32_INTRINSIC'
# define CRC32_INTRINSIC FIRST_32_SECOND_64(_mm_crc32_u32, _mm_crc32_u64)
^
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/../sanitizer_common/sanitizer_platform.h:132:36: note: expanded from macro 'FIRST_32_SECOND_64'
# define FIRST_32_SECOND_64(a, b) (a)
^
1 error generated.
For backwards compatibility, use `-mcrc32` when available and fall back
to `-msse4.2`. The `<smmintrin.h>` header remains in use as it still
works and is compatible with GCC, while clang's `<crc32intrin.h>`
is not.
Use __builtin_ia32*() rather than _mm_crc32*() when using `-mcrc32`
to preserve compatibility with GCC. _mm_crc32*() are aliases
to __builtin_ia32*() in both compilers but GCC requires `-msse4.2`
for the former, while both use `-mcrc32` for the latter.
Originally reported in https://bugs.gentoo.org/835870.
Differential Revision: https://reviews.llvm.org/D122789
This reverts commit 09b53121c3.
Breaks the build with GCC 11.2 on x86_64:
In file included from /home/npopov/repos/llvm-project/compiler-rt/lib/scudo/scudo_crc32.h:27,
from /home/npopov/repos/llvm-project/compiler-rt/lib/scudo/scudo_crc32.cpp:14:
/usr/lib/gcc/x86_64-redhat-linux/11/include/smmintrin.h: In function ‘__sanitizer::u32 __scudo::computeHardwareCRC32(__sanitizer::u32, __sanitizer::uptr)’:
/usr/lib/gcc/x86_64-redhat-linux/11/include/smmintrin.h:846:1: error: inlining failed in call to ‘always_inline’ ‘long long unsigned int _mm_crc32_u64(long long unsigned int, long long unsigned int)’: target specific option mismatch
846 | _mm_crc32_u64 (unsigned long long __C, unsigned long long __V)
On Darwin, we want to limit the parallelism during test execution for
sanitizer tests that use shadow memory. The reason is explained by this
existing comment:
> Only run up to 3 processes that require shadow memory simultaneously
> on 64-bit Darwin. Using more scales badly and hogs the system due to
> inefficient handling of large mmap'd regions (terabytes) by the
> kernel.
Previously we detected 3 cases:
* on-device: limit to 1 process
* 64-bit: macOS & simulators, limit to 3 processes
* others (32-bit): no limitation
We checked for the 64-bit case like this: `if arch in ['x86_64',
'x86_64h']` which misses macOS running on AS. Additionally, we don't
care about 32-bit anymore, so I've simplified this to 2 cases: on-device
and everything else.
Differential Revision: https://reviews.llvm.org/D122751
Update the hardware CRC32 logic in scudo to support using `-mcrc32`
instead of `-msse4.2`. The CRC32 intrinsics use the former flag
in the newer compiler versions, e.g. in clang since 12fa608af4.
With these compilers, passing `-msse4.2` is insufficient to enable
the instructions and causes build failures when `-march` does not enable
CRC32:
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/scudo_crc32.cpp:20:10: error: always_inline function '_mm_crc32_u32' requires target feature 'crc32', but would be inlined into function 'computeHardwareCRC32' that is compiled without support for 'crc32'
return CRC32_INTRINSIC(Crc, Data);
^
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/scudo_crc32.h:27:27: note: expanded from macro 'CRC32_INTRINSIC'
# define CRC32_INTRINSIC FIRST_32_SECOND_64(_mm_crc32_u32, _mm_crc32_u64)
^
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/../sanitizer_common/sanitizer_platform.h:132:36: note: expanded from macro 'FIRST_32_SECOND_64'
# define FIRST_32_SECOND_64(a, b) (a)
^
1 error generated.
For backwards compatibility, use `-mcrc32` when available and fall back
to `-msse4.2`. The `<smmintrin.h>` header remains in use as it still
works and is compatible with GCC, while clang's `<crc32intrin.h>`
is not.
Originally reported in https://bugs.gentoo.org/835870.
Differential Revision: https://reviews.llvm.org/D122789
dd9173420f (Add clear_cache implementation for ppc64. Fix buffer to
meet ppc64 alignment., 2017-07-28), adds an implementation for
__builtin___clear_cache on powerpc64, which was promptly ammended to
also be used with big endian mode in f67036b62c (This ppc64 implementation
of clear_cache works for both big and little endian., 2017-08-02)
clang will use this implementation for it's builtin on FreeBSD and result
in an abort() in the cases where 32-bit generation was requested (ex in
macppc or when the big endian powerpc64 build was done with "-m32") and as
reported[1] recently with pcre2, but there is no reason why the same code
couldn't be used in those cases, so use instead the more generic identifier
for the PowerPC architecture.
While at it, update the comment to reflect that POWER8/9 have a 128 byte
wide cache line and so the code could instead use 64 byte windows instead
but that possible optimization has been punted for now.
[1] https://github.com/PhilipHazel/pcre2/issues/92
Reviewed By: jhibbits, #powerpc, MaskRay
Differential Revision: https://reviews.llvm.org/D122640
* Support compiling with clang-5
* Check for `LLVM_DISABLE_ASSEMBLY_FILES` and have it set by
`compiler-rt/lib/sanitizer_common/symbolizer/scripts/build_symbolizer.sh`
which wants to receive and process only bitcode files.
This is a re-land of https://reviews.llvm.org/D86171 with fix.
Fuchsia's system libraries are instrumented and use the lsan
allocator for internal purposes. So leak checking needs to run
after all atexit hooks and after the system libraries' internal
exit-time hooks. The <zircon/sanitizer.h> hook API calls the
__sanitizer_process_exit_hook function at exactly the right time.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D88248
Add include to resolve compiler warning about no previous extern declaration for non-static HashAlgorithm
Differential Revision: https://reviews.llvm.org/D122630
Compiler warns about HeaderPos possibly being uninitialized which should not be possible, but just initialize it anyway
Differential Revision: https://reviews.llvm.org/D122632
Florian Mayer