Summary:
This issue from the bugzilla: https://bugs.llvm.org/show_bug.cgi?id=41177

When the two operands for BUILD_VECTOR are same, we will get assert error.
llvm::SDValue combineBVOfConsecutiveLoads(llvm::SDNode*, llvm::SelectionDAG&):
Assertion `!(InputsAreConsecutiveLoads && InputsAreReverseConsecutive) &&
"The loads cannot be both consecutive and reverse consecutive."' failed.

This error caused by the wrong ElemSIze when calling isConsecutiveLS(). We
should use `getScalarType().getStoreSize();` to get the ElemSize instread of
 `getScalarSizeInBits() / 8`.

Reviewed By: jsji

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

llvm-svn: 358644

llvm-svn: 358643

Patch by Jérémie Faucher-Goulet!

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

llvm-svn: 358642

llvm-svn: 358641

fneg combining attempts to turn it into fadd(fneg(A), fneg(0)), but
creating the new fadd folds to just fneg(A). When A has multiple uses,
this confuses it and you get an assert. Fixed.

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

Change-Id: I0ddc9b7286abe78edc0cd8d734fdeb05ff09821c
llvm-svn: 358640

llvm-svn: 358639

Patch by Gabriel Smith.

The address for a section would be evaluated before the region was
switched to. Because of this, the position within the region would not
be updated. After the region is swapped to the dot would be set to the
out of date position within the region, undoing the section address
evaluation.

To fix this, the region is swapped to before the section's address is
evaluated. As part of the fallout of this, expandMemoryRegions needed
to be gated in setDot on the condition that the evaluated address is
less than the dot. This is for the case where sections are not listed
from lowest address to highest address.

Finally, a test for the case where sections are listed "out of order"
was added.

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

llvm-svn: 358638

https://reviews.llvm.org/D60844

Use the style of buildInstr that allows CSEing.

llvm-svn: 358637

Reverse the checking of the domiance order so that when a self compare happens,
it returns false.  This makes compare function have strict weak ordering.

llvm-svn: 358636

Instead of parsing the Python version with a fairly convoluted regex,
just print the major and minor version and call it a day.

llvm-svn: 358635

This reverts r358628 (git commit 91a06bee)
while investigating a crash reproducer bot failure.

llvm-svn: 358634

new SemaModule.cpp.

llvm-svn: 358633

map being used for the module 'module.name'.

llvm-svn: 358632

global module fragment.

We know that the declaration in question should have been introduced by
a '#include', so try to figure out which one and suggest it. Don't
suggest importing the global module fragment itself!

llvm-svn: 358631

llvm-svn: 358630

[lldb] Don't filter variable list when doing a lookup by mangled name in SymbolFileDWARF::FindGlobalVariables

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

llvm-svn: 358629

to support APFS clones.

This patch adds a Darwin-specific implementation of
llvm::sys::fs::copy_file() that uses the macOS copyfile(3) API to
support APFS copy-on-write clones, which should be faster and much
more space efficient.

https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/APFS_Guide/ToolsandAPIs/ToolsandAPIs.html

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

llvm-svn: 358628

failing bots.

llvm-svn: 358627

llvm-svn: 358626

This is needed now that we marked lldb-test as EXCLUDE_ALL, to
make sure `ninja lldb-test-deps` doesn't fail.

llvm-svn: 358625

retaining block and all of the enclosing blocks are non-escaping.

If the block implicitly retaining self doesn't escape, there is no risk
of creating retain cycles, so clang shouldn't diagnose it and force
users to add self-> to silence the diagnostic.

Also, fix a bug where clang was failing to diagnose an implicitly
retained self inside a c++ lambda nested inside a block.

rdar://problem/25059955

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

llvm-svn: 358624

llvm-svn: 358623

The test file has pairs of tests that are logically equivalent:
https://rise4fun.com/Alive/2zQ

%t4 = and i8 %t1, 8
%t5 = zext i8 %t4 to i16
%sh = shl i16 %t5, 2
%t6 = add i16 %sh, %t0
=>
%t4 = and i8 %t1, 8
%sh2 = shl i8 %t4, 2
%z5 = zext i8 %sh2 to i16
%t6 = add i16 %z5, %t0

...so if we can fold the shift op into LEA in the 1st pattern, then we
should be able to do the same in the 2nd pattern (unnecessary 'movzbl'
is a separate bug I think).

We don't want to do this any sooner though because that would conflict
with generic transforms that try to narrow the width of the shift.

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

llvm-svn: 358622

Before the patch calling clang-tidy with -header-filter=.* -system-headers would
result in a few hundred useless warnings:
  warning: macro '_GNU_SOURCE' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
  warning: macro '_LP64' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
  warning: macro '__ATOMIC_ACQUIRE' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
  warning: macro '__ATOMIC_ACQ_REL' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
  warning: macro '__ATOMIC_CONSUME' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
  warning: macro '__ATOMIC_RELAXED' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
  warning: macro '__ATOMIC_RELEASE' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
  warning: macro '__ATOMIC_SEQ_CST' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
  warning: macro '__BIGGEST_ALIGNMENT__' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
  ... and so on

llvm-svn: 358621

Summary:
This check aims to address a relatively common benign error where
Objective-C subclass initializers call -self on their superclass instead
of invoking a superclass initializer, typically -init. The error is
typically benign because libobjc recognizes that improper initializer
chaining is common¹.

One theory for the frequency of this error might be that -init and -self
have the same return type which could potentially cause inappropriate
autocompletion to -self instead of -init. The equal selector lengths and
triviality of common initializer code probably contribute to errors like
this slipping through code review undetected.

This check aims to flag errors of this form in the interests of
correctness and reduce incidence of initialization failing to chain to
-[NSObject init].

[1] "In practice, it will be hard to rely on this function.
     Many classes do not properly chain -init calls."
From  _objc_rootInit in https://opensource.apple.com/source/objc4/objc4-750.1/runtime/NSObject.mm.auto.html.

Test Notes:
Verified via `make check-clang-tools`.

Subscribers: mgorny, xazax.hun, jdoerfert, cfe-commits

Tags: #clang

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

llvm-svn: 358620

Change-Id: I4d85123a157d957434902fb14ba50926b2d56212
llvm-svn: 358619

Summary:
X86 is quite complicated; so I intend to leave it as is. ARM+Aarch64 do
basically the same thing (Aarch64 did not correctly handle immediates,
ARM has a test llvm/test/CodeGen/ARM/2009-04-06-AsmModifier.ll that uses
%a with an immediate) for a flag that should be target independent
anyways.

Reviewers: echristo, peter.smith

Reviewed By: echristo

Subscribers: javed.absar, eraman, kristof.beyls, hiraditya, llvm-commits, srhines

Tags: #llvm

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

llvm-svn: 358618

Cleans up a bunch of places where we do getSize() * 8.

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

llvm-svn: 358617

It turns out that whether the new handlers should be provided is orthogonal
to whether new/delete are provided in libc++ or libc++abi. The reason why
I initially added this conditional is because of an incorrect understanding
of the path we're taking when building on Apple platforms. In fact, we
always build libc++ on top of libc++abi on Apple platforms, so we take
the branch for `LIBCXX_BUILDING_LIBCXXABI` there.

llvm-svn: 358616

<rdar://problem/49925960>

llvm-svn: 358615

Some linker libraries are only needed for shared libc++, some only
for static libc++, combining these together in LIBCXX_LIBRARIES and
LIBCXX_INTERFACE_LIBRARIES can introduce unnecessary dependencies.

This changes splits those up into LIBCXX_SHARED_LIBRARIES and
LIBCXX_STATIC_LIBRARIES matching what libc++abi already does.

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

llvm-svn: 358614

Legalize things like i24 load/store by splitting them into smaller power of 2 operations.

This matches how SelectionDAG handles these operations.

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

llvm-svn: 358613

[clangd] Strip the ' [some-check-name]' suffix from clang-tidy diagnostics. The check name is reported in Diagnostic.code.

Reviewers: kadircet

Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, cfe-commits

Tags: #clang

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

llvm-svn: 358612

Summary:
 - for warnings, use the flag the warning is controlled by (-Wfoo)
 - for errors, keep using the internal name (there's nothing better) but
   drop the err_ prefix

This comes at the cost of uniformity, it's no longer totally obvious
exactly what the code field contains. But the -Wname flags are so much
more useful to end-users than the internal warn_foo that this seems worth it.

Reviewers: kadircet

Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, cfe-commits

Tags: #clang

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

llvm-svn: 358611

In r358591, I added a test that uses the debug database from multiple
threads and that helped us uncover the problem that was fixed in r355367.
However, the test broke the tsan CI bots, and I think the problem is the
test allocator that was used in the test (which is not thread safe).

I'm committing again without using the test allocator, and in a separate
test file.

llvm-svn: 358610

For the following code snippet:

void builtin_function_call_crash_fixes(char *c) {
  __builtin_strncpy(c, "", 6);
  __builtin_memset(c, '\0', (0));
  __builtin_memcpy(c, c, 0);
}
security.insecureAPI.DeprecatedOrUnsafeBufferHandling caused a regression, as it
didn't recognize functions starting with __builtin_. Fixed exactly that.

I wanted to modify an existing test file, but the two I found didn't seem like
perfect candidates. While I was there, I prettified their RUN: lines.

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

llvm-svn: 358609

It's possible to build just the headers, and we actually do it.

llvm-svn: 358608

This patch adds a basic loop fusion pass. It will fuse loops that conform to the
following 4 conditions:
  1. Adjacent (no code between them)
  2. Control flow equivalent (if one loop executes, the other loop executes)
  3. Identical bounds (both loops iterate the same number of iterations)
  4. No negative distance dependencies between the loop bodies.

The pass does not make any changes to the IR to create opportunities for fusion.
Instead, it checks if the necessary conditions are met and if so it fuses two
loops together.

The pass has not been added to the pass pipeline yet, and thus is not enabled by
default. It can be run stand alone using the -loop-fusion option.

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

llvm-svn: 358607

Summary:
Typically used with umbrella headers, e.g. GTK:

 #if !defined (__GTK_H_INSIDE__) && !defined (GTK_COMPILATION)
 #error "Only <gtk/gtk.h> can be included directly."
 #endif

Heuristic is fairly conservative, a quick code search over github showed
a fair number of hits and few/no false positives. (Not all were umbrella
headers, but I'd be happy avoiding include insertion for all of them).

We may want to relax the heuristic later to catch more cases.

Reviewers: ioeric

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

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

llvm-svn: 358605

We were using the LLDB-Info.plist as the canonical holder of the
version number, but there is really no good reason to do this. If
anything the plist should be generated using the information provided
to CMake.

For now just remove the logic extracting the version from the plist
and rely on LLDB_VERSION_STRING.

llvm-svn: 358604