llvm-svn: 299083

Summary:
This is already assumed by the test suite, and by
asan_flags.cc.

Reviewers: m.ostapenko, vitalybuka, kubamracek, kcc

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D31462

llvm-svn: 299082

llvm-svn: 299081

an ObjC object pointer

When ARC is enabled in Objective-C++, comparisons between a pointer and
Objective-C object pointer typically result in errors like this:
"invalid operands to a binary expression". This error message can be quite
confusing as it doesn't provide a solution to the problem, unlike the non-C++
diagnostic: "implicit conversion of Objective-C pointer type 'id' to C pointer
type 'void *' requires a bridged cast" (it also provides fix-its). This commit
forces comparisons between pointers and Objective-C object pointers in ARC to
use the Objective-C semantic rules to ensure that a better diagnostic is
reported.

rdar://31103857

Differential Revision: https://reviews.llvm.org/D31177

llvm-svn: 299080

llvm-svn: 299079

warning for methods that resemble the setters of readonly properties

rdar://30415679

llvm-svn: 299078

I am working on improving our internal bot infrastructure. One thing
that is unique to the ps4 is that we want to run the posix tests, but
have to execute them on windows.

We currently have a local hack to use a shell on windows, but it is
pretty much impossible to get all all the tools to play nice with all
the heuristics for what is a path and what is a command line option.

This adds support LIT_USE_INTERNAL_SHELL and I will then try to fix
the tests that fail with it but adding the missing features.

llvm-svn: 299077

Using count is more common in llvm and avoids a subshell.

llvm-svn: 299076

Correct assertion messages in MachineOperand for some of the setters.

llvm-svn: 299075

Based on corrections mentioned in patch for clang for PR27635

llvm-svn: 299074

Reviewers: ioeric

Reviewed By: ioeric

Subscribers: alexshap, klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D31492

llvm-svn: 299073

Based on corrections mentioned in patch for clang for PR27635

llvm-svn: 299072

Fix for sphinx-doc warnings in r299068.

llvm-svn: 299071

Speculative fix for linker errors in r299068.

llvm-svn: 299070

llvm-svn: 299069

Summary: Add some hicpp checks that can be implmented as alises for existing clang-tidy checks:
hicpp-explicit-conversions
hicpp-function-size
hicpp-named-parameter
hicpp-invalid-access-moved
hicpp-member-init
hicpp-new-delete-operators
hicpp-noexcept-move
hicpp-special-member-functions
hicpp-undelegated-constructor
hicpp-use-equals-default
hicpp-use-equals-delete
hicpp-use-override

Reviewers: dberlin, jbcoe, aaron.ballman, alexfh

Reviewed By: aaron.ballman

Subscribers: JDevlieghere

Differential Revision: https://reviews.llvm.org/D30383

Patch By: Jonas Toth

llvm-svn: 299068

This reverts r299062, which caused build failures on Windows.
It also reverts the attempts to fix the windows builds in r299064 and r299065.
The introduction of namespace llvm::sys::detail makes MSVC, and seemingly also
mingw, complain about ambiguity with the existing namespace llvm::detail.
E.g.:
C:\b\slave\sanitizer-windows\llvm\include\llvm/Support/MathExtras.h(184): error C2872: 'detail': ambiguous symbol
C:\b\slave\sanitizer-windows\llvm\include\llvm/Support/PointerLikeTypeTraits.h(31): note: could be 'llvm::detail'
C:\b\slave\sanitizer-windows\llvm\include\llvm/Support/Host.h(80): note: or       'llvm::sys::detail'

In r299064 and r299065 I tried to fix these ambiguities, based on the errors
reported in the log files. It seems however that the build stops early when
this kind of error is encountered, and many build-then-fix-iterations on
Windows may be needed to fix this. Therefore reverting r299062 for now to
get the build working again on Windows.

llvm-svn: 299066

By changing more detail::... to llvm::detail::...

llvm-svn: 299065

llvm-svn: 299064

Functions that still return Expected<X> are now called createAndImport*()

Changing the return type was requested in the review comments for r299001

llvm-svn: 299063

Based on post-commit review comments by Chandler Carruth on
https://reviews.llvm.org/D31236. Thanks!

llvm-svn: 299062

{M, T, E}San have fread and fwrite interceptors, let's move them to sanitizer_common to enable ASan checks as well.

Differential Revision: https://reviews.llvm.org/D31456

llvm-svn: 299061

This refactors getHostCPUName so that for the architectures that get the
host cpu info on linux from /proc/cpuinfo, the /proc/cpuinfo parsing
logic is present in the build, even if it wasn't built on a linux system
for that architecture.

Since the code is present in the build, we can then test that code also
on other systems, i.e. we don't need to have buildbots setup for all
architectures on linux to be able to test this. Instead, developers will
test this as part of the regression test run.

As an example, a few unit tests are added to test getHostCPUName for ARM
running linux. A unit test is preferred over a lit-based test, since the
expectation is that in the future, the functionality here will grow over
what can be tested with "llc -mcpu=native".

This is a preparation step to enable implementing the range of
improvements discussed on PR30516, such as adding AArch64 support,
support for big.LITTLE systems, reducing code duplication.

Differential Revision: https://reviews.llvm.org/D31236

llvm-svn: 299060

Turns out integerPartWidth only explicitly defines the width of the tc functions in the APInt class. Functions that aren't used by APInt implementation itself. Many places in the code base already assume APInt is made up of 64-bit pieces. Explicitly assuming 64-bit here doesn't make that situation much worse. A full audit would need to be done if it ever changes.

llvm-svn: 299059

Turns out integerPartWidth only explicitly defines the width of the tc functions in the APInt class. Functions that aren't used by APInt implementation itself. Many places in the code base already assume APInt is made up of 64-bit pieces. Explicitly assuming 64-bit here doesn't make that situation much worse. A full audit would need to be done if it ever changes.

llvm-svn: 299058

llvm-svn: 299057

Actually fix (hopefully) the assertions about `use_system_cxx_lib`,
the previous attempt failed because I misread the error.

llvm-svn: 299056

Fix the libc++ Green Dragon bot.

llvm-svn: 299055

Both libc++ and libc++abi export a weak definition of operator
new/delete. On Darwin, this can often cause dirty __DATA in the
shared cache when having to switch from one to the other. Instead,
libc++ should reexport libc++abi's implementation of these symbols.

Patch by: Ted Kremenek <kremenek@apple.com>

Differential Revision: https://reviews.llvm.org/D30765

llvm-svn: 299054

As we're trying to setup testing / bots for all shipping version of libc++
on macOS/iOS, we'll need to be able to pass a path to where to find the
dylib for each previous version of the OS.

Differential Revision: https://reviews.llvm.org/D31486

llvm-svn: 299053

Do not pass an explicit reexported symbol list when building libc++ dylib if also defining new/delete

llvm-svn: 299052

[libFuzzer] remove a stale flag from tests, run value-profile-strncmp.test longer (hopefully, will fix the OSX bot)

llvm-svn: 299051

Until llvm-xray starts running/supporting binaries that are not ELF64 we
only run the FDR tests on x86_64-linux. Previous changes caused the
tests to not actually run on x86_64.

Follow-up on D31454.

llvm-svn: 299050

Followup on D31454.

llvm-svn: 299049

Followup on D31454.

llvm-svn: 299048

Summary:
Add a simplification:
shuffle (splat-shuffle), undef, M --> splat-shuffle

Fixes pr32449

Patch by Sanjay Patel

Reviewers: eli.friedman, RKSimon, spatel

Reviewed By: spatel

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D31426

llvm-svn: 299047

[libFuzzer] best effort support for -fsanitize-coverage=trace-pc instrumentation. It is less efficient and precise than -fsanitize-coverage=trace-pc-guard, but still works

llvm-svn: 299046

Fixes this clang warning on Windows:

warning: implicit truncation from 'clang::LangOptions::FPContractModeKind' to bit-field changes value from 2 to -2 [-Wbitfield-constant-conversion]
    fp_contract = LangOptions::FPC_Fast;
                ^ ~~~~~~~~~~~~~~~~~~~~~
llvm-svn: 299045

This should unbreak some bots.

Follow-up on D30388.

llvm-svn: 299044

When -fsanitize-address-use-after-scope is used, the instrumentation produces line numbers in stack frame descriptions. This patch make sure the ASan runtime supports this format (ParseFrameDescription needs to be able to parse "varname:line") and prepares lit tests to allow line numbers in ASan report output.

Differential Revision: https://reviews.llvm.org/D31484

llvm-svn: 299043