Remove extra semicolon: Target.cpp:187:2: warning: extra ‘;’ [-Wpedantic]

llvm-svn: 374147

Summary:
This will help for PR32326.

This shows the well-known issue with `RBP` and `R13` as base registers.

Reviewers: gchatelet

Subscribers: tschuett, llvm-commits, RKSimon, andreadb

Tags: #llvm

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

llvm-svn: 374146

When playing with the C++ module prototype I noticed I can get LLDB to crash
by making a result type that depends on __make_integer_seq (a BuiltinTemplate)
which is not supported by the ASTImporter yet. This causes the ASTImporter to emit
a diagnostic when copying the type to the ScratchASTContext. As deporting the result
type is done after we are done parsing and the Clang's diagnostic engine asserts that
it can only be used during parsing, it crashes LLDB while trying to render the diagnostic
in the HandleDiagnostic method of ClangDiagnosticManagerAdapter.

This patch just moves the HandleDiagnostic call to Clang behind our check that we still
have a DiagnosticManager (which we remove after parsing) which prevents the assert
from firing. We also shouldn't ignore such diagnostics, so I added a log statement for
them.

There doesn't seem to way to test this as these diagnostic only happen when we copy
a node that's not supported by the ASTImporter which should never happen once
we can copy everything with the ASTImporter, so every test case we add here will
eventually become invalid.

(Note that most of this diff is just whitespace changes as we now use an early exit
instead of a huge 'if' block).

llvm-svn: 374145

The added test files ("com", "com1.o", "com2.o") are reserved names on
Windows, and makes 'git checkout' fail with a filesystem error.

llvm-svn: 374144

We've been in namespace llvm for at least a year.

llvm-svn: 374143

Suggested by Martin Storsjö.

llvm-svn: 374142

Fixes assert in addLinkerModuleCoffGroup() when using by-ordinal imports
only.

Patch by Stefan Schmidt.

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

llvm-svn: 374140

For common symbols the linker emits only a single symbol entry in the
debug map. This caused dsymutil to not relocate common symbols when
linking DWARF coming form object files that did not have this entry.
This patch fixes that by keeping track of common symbols in the object
files and synthesizing a debug map entry for them using the address from
the main binary.

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

llvm-svn: 374139

TypeSize.h uses `assert` statements without including
the <cassert> header first which leads to failures
in modular builds.

llvm-svn: 374138

Patch by Martijn Vels (mvels@google.com)
Reviewed as https://reviews.llvm.org/D68276

This is a non trivial win for externally templated assignment operator.

x86 without tail call (current libc++)

0000000000000000 <std::string::operator=(std::string const&)>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   53                      push   %rbx
   5:   50                      push   %rax
   6:   48 89 fb                mov    %rdi,%rbx
   9:   48 39 f7                cmp    %rsi,%rdi
   c:   74 17                   je     25 <std::string::operator=(std::string const&)+0x25>
   e:   0f b6 56 17             movzbl 0x17(%rsi),%edx
  12:   84 d2                   test   %dl,%dl
  14:   79 07                   jns    1d <std::string::operator=(std::string const&)+0x1d>
  16:   48 8b 56 08             mov    0x8(%rsi),%rdx
  1a:   48 8b 36                mov    (%rsi),%rsi
  1d:   48 89 df                mov    %rbx,%rdi
  20:   e8 00 00 00 00          callq  25 <std::string::operator=(std::string const&)+0x25>
  25:   48 89 d8                mov    %rbx,%rax
  28:   48 83 c4 08             add    $0x8,%rsp
  2c:   5b                      pop    %rbx
  2d:   5d                      pop    %rbp
  2e:   c3                      retq

After:

0000000000000000 <std::string::operator=(std::string const&)>:
   0:   48 39 f7                cmp    %rsi,%rdi
   3:   74 14                   je     19 <std::string::operator=(std::string const&)+0x19>
   5:   0f b6 56 17             movzbl 0x17(%rsi),%edx
   9:   84 d2                   test   %dl,%dl
   b:   79 07                   jns    14 <std::string::operator=(std::string const&)+0x14>
   d:   48 8b 56 08             mov    0x8(%rsi),%rdx
  11:   48 8b 36                mov    (%rsi),%rsi
  14:   e9 00 00 00 00          jmpq   19 <std::string::operator=(std::string const&)+0x19>
  19:   48 89 f8                mov    %rdi,%rax
  1c:   c3                      retq

Benchmark (pending per https://reviews.llvm.org/D67667)

```
BM_StringAssignStr_Empty_Opaque                     6.23ns ± 0%             5.19ns ± 0%  -16.70%          (p=0.016 n=5+4)
BM_StringAssignStr_Empty_Transparent                5.86ns ± 0%             5.14ns ± 0%  -12.24%          (p=0.008 n=5+5)
BM_StringAssignStr_Small_Opaque                     8.79ns ± 1%             7.69ns ± 0%  -12.53%          (p=0.008 n=5+5)
BM_StringAssignStr_Small_Transparent                9.44ns ± 0%             8.00ns ± 0%  -15.26%          (p=0.008 n=5+5)
BM_StringAssignStr_Large_Opaque                     25.2ns ± 0%             24.3ns ± 0%   -3.50%          (p=0.008 n=5+5)
BM_StringAssignStr_Large_Transparent                23.6ns ± 0%             22.5ns ± 0%   -4.76%          (p=0.008 n=5+5)
BM_StringAssignStr_Huge_Opaque                       319ns ± 5%              317ns ± 5%     ~             (p=0.690 n=5+5)
BM_StringAssignStr_Huge_Transparent                  319ns ± 5%              317ns ± 5%     ~             (p=0.421 n=5+5)
BM_StringAssignAsciiz_Empty_Opaque                  7.41ns ± 0%             7.77ns ± 0%   +4.89%          (p=0.008 n=5+5)
BM_StringAssignAsciiz_Empty_Transparent             7.54ns ± 3%             7.30ns ± 0%   -3.24%          (p=0.008 n=5+5)
BM_StringAssignAsciiz_Small_Opaque                  9.87ns ± 0%            10.24ns ± 1%   +3.76%          (p=0.008 n=5+5)
BM_StringAssignAsciiz_Small_Transparent             10.4ns ± 1%              9.8ns ± 2%   -5.78%          (p=0.008 n=5+5)
BM_StringAssignAsciiz_Large_Opaque                  30.1ns ± 0%             30.1ns ± 0%     ~             (p=0.167 n=5+5)
BM_StringAssignAsciiz_Large_Transparent             27.1ns ± 0%             27.4ns ± 0%   +0.92%          (p=0.016 n=4+5)
BM_StringAssignAsciiz_Huge_Opaque                    383ns ± 4%              382ns ± 4%     ~             (p=0.548 n=5+5)
BM_StringAssignAsciiz_Huge_Transparent               375ns ± 0%              380ns ± 0%   +1.37%          (p=0.029 n=4+4)
BM_StringAssignAsciizMix_Opaque                     14.0ns ± 0%             14.0ns ± 0%     ~             (p=0.881 n=5+5)
BM_StringAssignAsciizMix_Transparent                13.7ns ± 1%             13.8ns ± 0%     ~             (p=0.056 n=5+5)
```

llvm-svn: 374137

whose value is not ignored.

We don't warn on all the cases that are deprecated: specifically, we
choose to not warn for now if there are parentheses around the
assignment but its value is not actually used. This seems like a more
defensible rule, particularly for cases like sizeof(v = a), where the
parens are part of the operand rather than the sizeof syntax.

llvm-svn: 374135

Diagnose some now-deprecated uses of volatile types:
 * as function parameter types and return types
 * as the type of a structured binding declaration
 * as the type of the lvalue operand of an increment / decrement /
   compound assignment operator

This does not implement a check for the deprecation of simple
assignments whose results are used; that check requires somewhat
more complexity and will be addressed separately.

llvm-svn: 374133

Summary:
This is a redo of D68069 because I reverted it due to some concerns that were now addressed along with the new comments that @labath added.

I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb).
The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash.
This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb.

I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code.

I also run the following on the command line with the `app_process32` where I found the issue:
**Before:**
```
(lldb) dis -s 0x1640 -e 0x1644
app_process32[0x1640]: .long  0xf0004668                ; unknown opcode
```
**After:**
```
(lldb) dis -s 0x1640 -e 0x1644
app_process32`:
app_process32[0x1640] <+0>: mov    r0, sp
app_process32[0x1642]:      andeq  r0, r0, r0
```

Reviewers: clayborg, labath, wallace, espindola

Reviewed By: labath

Subscribers: labath, lldb-commits, MaskRay, kristof.beyls, arichardson, emaste, srhines

Tags: #lldb

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

llvm-svn: 374132

version 9.

llvm-svn: 374131

llvm-svn: 374130

llvm-svn: 374129

Removes label ref pointing to non-existent subsystem docs page.

llvm-svn: 374128

The existing string/character literal skipping code in the
dependency directives source minimizer has two issues:

- It doesn't stop the scanning when a newline is reached before the terminating character,
unlike the lexer which considers the token to be done (even if it's invalid) at the end of the line.

- It doesn't support whitespace between '\' and the newline when looking if the '\' is used as a line continuation character.

This commit fixes both issues.

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

llvm-svn: 374127

When passing arguments using temporary allocas, we need to add the
appropriate lifetime markers so that the stack coloring passes can
re-use the stack space.

This patch keeps track of all the lifetime.start calls emited before the
codegened call, and adds the corresponding lifetime.end calls after the
call.

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

llvm-svn: 374126

llvm-svn: 374125

Test with the last eight bits within the range [7F, FF] and with
lower-case hex letters.

llvm-svn: 374124

The verbose output for finding relocations assumed that we'd always dump
the DIE after (which starts with a newline) and therefore didn't include
one itself. However, this isn't always true, leading to garbled output.

This patch adds a newline to the verbose output and adds a line that
says that the DIE is being kept (which isn't obvious otherwise). It also
adds a 0x prefix to the relocations.

llvm-svn: 374123

llvm-svn: 374122

This reverts r374117 (git commit 6399db2f)
while inspecting bot breakage.

llvm-svn: 374121

llvm-svn: 374120

"non-constant" value.

If the constant evaluator evaluates part of a variable initializer,
including the initializer for some lifetime-extended temporary, but
fails to fully evaluate the initializer, it can leave behind wrong
values for temporaries encountered in that initialization. Don't try to
emit those from CodeGen! Instead, look at the values that constant
evaluation produced if (and only if) it actually succeeds and we're
emitting the lifetime-extending declaration's initializer as a constant.

llvm-svn: 374119

Reviewers: chandlerc, jlpeyton, jdoerfert, dim

Reviewed-By: dim

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

llvm-svn: 374118

When ingesting aranges from a dSYM it makes sense to always trust the
contents of the accelerator table since it always comes from
dsymutil. According to Instruments, skipping the decoding of all CU
DIEs to get at the DW_AT_ranges attribute removes ~3.5 seconds from
setting a breakpoint by file/line when debugging clang with a
dSYM. Interestingly on the wall clock the speedup is less noticeable,
but still present.

rdar://problem/56057688

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

llvm-svn: 374117

Summary:
This allows the linker script generation to query CMake properties
(specifically the dependencies of libc++.so) instead of having to
carry these dependencies around manually in global variables. Notice
the removal of the LIBCXX_INTERFACE_LIBRARIES global variable.

Reviewers: phosek, EricWF

Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits

Tags: #libc

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

llvm-svn: 374116

llvm-svn: 374115

LLDB appears to have at least partial support for PPC, but PPC on Mach
isn't a thing AFAIK.

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

llvm-svn: 374114

Reviewers: rnk

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 374113

Summary:
zero-extension is far more friendly for further analysis.
While this doesn't directly help with the shift-by-signext problem, this is not unrelated.

This has the following effect on test-suite (numbers collected after the finish of middle-end module pass manager):
| Statistic                            |     old |     new | delta | percent change |
| correlated-value-propagation.NumSExt |       0 |    6026 |  6026 |   +100.00%     |
| instcount.NumAddInst                 |  272860 |  271283 | -1577 |     -0.58%     |
| instcount.NumAllocaInst              |   27227 |   27226 | -1    |      0.00%     |
| instcount.NumAndInst                 |   63502 |   63320 | -182  |     -0.29%     |
| instcount.NumAShrInst                |   13498 |   13407 | -91   |     -0.67%     |
| instcount.NumAtomicCmpXchgInst       |    1159 |    1159 |  0    |      0.00%     |
| instcount.NumAtomicRMWInst           |    5036 |    5036 |  0    |      0.00%...

llvm-svn: 374111

llvm-svn: 374110

Summary:
It seems that compiler-rt's implementation and Darwin
libm's implementation of `logbf()` differ when given a NaN
with raised sign bit. Strangely this behaviour only happens with
i386 Darwin libm. For x86_64 and x86_64h the existing compiler-rt
implementation matched Darwin libm.

To workaround this the `compiler_rt_logbf_test.c` has been modified
to do a comparison on the `fp_t` type and if that fails check if both
values are NaN. If both values are NaN they are equivalent and no
error needs to be raised.

rdar://problem/55565503

Reviewers: rupprecht, scanon, compnerd, echristo
Subscribers: #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D67999

llvm-svn: 374109

TestCPP11EnumTypes.py should have covered all our bases when it comes
to typed enums, but it missed the regression introduced in r374066.
The reason it didn't catch it is somewhat funny: the test was copied
over from another test that recompiled a source file with a different
base type every time, but neither the test source nor the python code
was adapted for testing enums. As a result, this test was just running
8 times the exact same checks on the exact same binary.

This commit fixes the coverage and addresses the issue revealed by
the new tests.

llvm-svn: 374108

and of vendors, not or.

If several vendors are provided in the same vendor context trait, the
context shall match only if all vendors are matching, not one of them.
This is per OpenMP 5.0, 2.3.3 Matching and Scoring Context Selectors,
all selectors in the construct, device, and implementation sets of the
context selector appear in the corresponding trait set of the OpenMP
context.

llvm-svn: 374107

llvm-svn: 374106

llvm-svn: 374105