This fixes all cases of errors in asan+ubsan builds.

Also use std::copy instead of if+memcpy in the previously updated spot,
for consistency.

llvm-svn: 349826

__builtin_cpu_supports and __builtin_cpu_is use information in __cpu_model to decide cpu features. Before this change, __cpu_model was not declared as dso local. The generated code looks up the address in GOT when reading __cpu_model. This makes it impossible to use these functions in ifunc, because at that time GOT entries have not been relocated. This change makes it dso local.

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

llvm-svn: 349825

Since r348038 we emit an error every time an -analyzer-config option is not
found. The driver, however, suppresses this error with another flag,
-analyzer-config-compatibility-mode, so backwards compatibility is maintained,
while analyzer developers still enjoy the new typo-free experience.

The backwards compatibility turns out to be still broken when the -analyze
action is not specified; it is still possible to specify -analyzer-config
in that case. This should be fixed now.

Patch by Kristóf Umann!

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

rdar://problem/46504165

llvm-svn: 349824

Instead of generating llvm.mem.parallel_loop_access metadata, generate
llvm.access.group on instructions and llvm.loop.parallel_accesses on
loops. There is one access group per generated loop.

This is clang part of D52116/r349725.

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

llvm-svn: 349823

If you don't do this, then if you hit a G_LOAD in getInstrMapping, you'll end
up with GPRs on the G_FCEIL instead of FPRs. This causes a fallback.

Add it to the switch, and add a test verifying that this happens.

llvm-svn: 349822

Removes redundant calls to ::get() from smart pointers in the source/API
directory..

llvm-svn: 349821

SFINAE failures.

llvm-svn: 349820

When deciding lazily whether a CU would be split or non-split I
accidentally dropped some handling for the line tables comp_dir (by
doing it lazily it was too late to be handled properly by the MC line
table code).

Move that bit of the code back to the non-lazy place.

llvm-svn: 349819

Unexpected successes should be considered failures because they can hide
regressions when not addressed. When a test is fixed and not re-enabled,
it can easily regress without us noticing.

I couldn't find a good way to make this change other than changing it in
the unittest2 framework. I know this is less than optimal but since we
have the dependency checked in and the change is pretty fundamental to
the framework I think it's not unreasonable.

Differential revision: https://reviews.llvm.org/D55835

llvm-svn: 349818

Summary:
Support running with no open file descriptors (as may happen to
"init" process on linux).
* Remove a check that writing to stderr succeeds.
* When opening a file (ex. for log_path option), dup the new fd out of
[0, 2] range to avoid confusing the program.

(2nd attempt, this time without the sanitizer_rtems change)

Reviewers: pcc, vitalybuka

Subscribers: kubamracek, llvm-commits

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

llvm-svn: 349817

llvm-svn: 349816

llvm-svn: 349815

llvm-svn: 349814

Several of the tests are now passing. This change is enabling them.

llvm-svn: 349813

This adds anchors to all of the documented checks so that you can directly link to a check by a stable name. This is useful because the SARIF file format has a field for specifying a URI to documentation for a rule and some viewers, like CodeSonar, make use of this information. These links are then exposed through the SARIF exporter.

llvm-svn: 349812

When checking that the array access is not out-of-bounds in CheckArrayAccess
it is possible that the type of the base expression after IgnoreParenCasts is
incomplete, even though the type of the base expression before IgnoreParenCasts
is complete. In this case we have no information about whether the array access
is out-of-bounds and we should just bail-out instead. This fixes PR39746 which
was caused by trying to obtain the size of an incomplete type.

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

Reviewed By: efriedma

llvm-svn: 349811

It is invalid to call memcpy with a null pointer, even if the size
is zero.

This should fix the sanitizer buildbot.

llvm-svn: 349808

Move constant folding tests into ConstantFolding/bitcount.ll and drop
various tests in other places. Add coverage for undefs.

llvm-svn: 349806

llvm-svn: 349805

Bring overflow-ops.ll into current format. Remove redundant entry
blocks.

llvm-svn: 349804

llvm-svn: 349803

llvm-svn: 349802

Split each test into a separate function.

llvm-svn: 349801

We have to treat constructs like this as if they were "symbolic", to use
the correct codepath to resolve them.  This mostly only affects movz
etc. because the other uses of classifySymbolRef conservatively treat
everything that isn't a constant as if it were a symbol.

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

llvm-svn: 349800

This requires a bit more code than other fixups, to distingush between
abs_g0/abs_g1/etc.  Actually, I think some of the other fixups are
missing some checks, but I won't try to address that here.

I haven't seen any real-world code that uses a construct like this, but
it clearly should work, and we're considering using it in the
implementation of localescape/localrecover on Windows (see
https://reviews.llvm.org/D53540). I've verified that binutils produces
the same code as llvm-mc for the testcase.

This currently doesn't include support for the *_s variants (that
requires a bit more work to set the opcode).

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

llvm-svn: 349799

This reverts commit r349701.

The patch was incorrect. The whole point of CastRetrievedVal()
is to handle the case in which the type from which the cast is made
(i.e., the "type" of value `V`) has nothing to do with the type of
the region it was loaded from (i.e., `R->getValueType()`).

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

rdar://problem/45062567

llvm-svn: 349798

This emits FSHL/FSHR generic intrinsics for the XOP VPROT and AVX512 VPROL/VPROR rotation intrinsics.

LLVM counterpart: https://reviews.llvm.org/D55938

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

llvm-svn: 349796

This emits FSHL/FSHR generic intrinsics for the XOP VPROT and AVX512 VPROL/VPROR rotation intrinsics.

Clang counterpart: https://reviews.llvm.org/D55937

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

llvm-svn: 349795

If we found unsafe dependences other than 'unknown', we already know at
compile time that they are unsafe and the runtime checks should always
fail. So we can avoid generating them in those cases.

This should have no negative impact on performance as the runtime checks
that would be created previously should always fail. As a sanity check,
I measured the test-suite, spec2k and spec2k6 and there were no regressions.

Reviewers: Ayal, anemet, hsaito

Reviewed By: Ayal

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

llvm-svn: 349794

Thanks to Galina Kistanova for pointing this out!

llvm-svn: 349793

Reviewers: zturner

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits

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

llvm-svn: 349792

This test is now marked as unsupported on Windows - it is not technically  "unsupported" on Windows, but it fails because "expr ptr" does not evaluate correctly. However, the error message contains the expected string, so the test "passes" despite the fact that the commands failed
The following bug has been opened for it: llvm.org/pr40119

llvm-svn: 349784

Both of these are now passing. I've resolved the bugs as well for verification.

llvm-svn: 349783

Calls to this function are deleted in the ARC optimizer.  However when the ARC
optimizer was updated to use intrinsics instead of functions (r349534), the corresponding
clang change (r349535) to use intrinsics missed this one so it wasn't being deleted.

llvm-svn: 349782

There are a couple of tests in TestEvents that are now passing.

llvm-svn: 349781

Some tests assume that iteration through an unordered multimap elements
will return them in the same order as at the container creation. This
assumption is not true since the container is unordered, so that no
specific order of elements is ever guaranteed for such container. This
patch introduces checks verifying that any iteration will return elements
exactly from a set of valid values and without repetition, but in no
particular order.

Reviewed as https://reviews.llvm.org/D54838.
Thanks to Andrey Maksimov for the patch.

llvm-svn: 349780

Summary:
Add PLATFORM constants for iOS, tvOS, and watchOS simulators, as well
as human readable names for these constants, to the Mach-O file format
header files. 

rdar://46854119

Reviewers: ab, davide

Reviewed By: ab, davide

Subscribers: llvm-commits

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

llvm-svn: 349779

Build llvm with assertion on, and then build bcc against this llvm.
Run any bcc tool with debug=8 (turning on -g for clang compilation),
you will get the following assertion errors,
  /home/yhs/work/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:888:
  void llvm::RuntimeDyldELF::resolveBPFRelocation(const llvm::SectionEntry&, uint64_t,
    uint64_t, uint32_t, int64_t): Assertion `Value <= (4294967295U)' failed.

The .BTF.ext ELF section uses Fixup's to get the instruction
offsets. The data width of the Fixup is 4 bytes since we only need
the insn offset within the section.

This caused the above error though since R_BPF_64_32 expects
4-byte value and the Runtime Dyld tried to resolve the actual
insn address which is 8 bytes.

Actually the offset within the section is all what we need.
Therefore, there is no need to perform any kind of relocation
for .BTF.ext section and such relocation will actually cause
incorrect result.

This patch changed BPFELFObjectWriter::getRelocType() such that
for Fixup Kind FK_Data_4, if the relocation Target is a temporary
symbol, let us skip the relocation (ELF::R_BPF_NONE).

Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Yonghong Song <yhs@fb.com>
llvm-svn: 349778

[CodeView] Emit global variables within lexical scopes to limit visibility

Emit static locals within the correct lexical scope so variables with the same
name will not confuse the debugger into getting the wrong value.

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

llvm-svn: 349777

llvm-svn: 349776