Summary:
Qsort interceptor suppresses all checks by unpoisoning the data in the
wrapper of a comparator function, and then unpoisoning the output array
as well.

This change adds an explicit run of the comparator on all elements of
the input array to catch any sanitizer bugs.

Reviewers: vitalybuka

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

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

The checker can diagnose handle use after releases, double releases, and
handle leaks.

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

Summary:
This fixes qsort-related false positives with glibc-2.27.
I'm not entirely sure why they did not show up with the earlier
versions; the code seems similar enough.

Reviewers: vitalybuka

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

Demote member functions to static functions where possible
Use early continue/early return to reduce nesting
Clarify comments slightly.
Reuse previously define expression in one case.

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

Should have caught this in review, but only noticed when addressing post commit style items.  We were creating a new instance of the X86MCInstrInfo class, and then never reclaiming the memory.  This wasn't even conditional on the new off by default flags, so it was an unconditional leak.

Comment and adjust style in the newly introduced MCBoundaryAlignFragment infrastructure.  More to follow.

These annotations will be used in an upcomming static analyzer check
that finds handle leaks, use after releases, and double releases.

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

WARNING: If you're looking at this patch because you're looking for a full
performace mitigation of the Intel JCC Erratum, this is not it!

This is a preliminary patch on the patch towards mitigating the performance
regressions caused by Intel's microcode update for Jump Conditional Code
Erratum.  For context, see:
https://www.intel.com/content/www/us/en/support/articles/000055650.html

The patch adds the required assembler infrastructure and command line options
needed to exercise the logic for INTERNAL TESTING.  These are NOT public flags,
and should not be used for anything other than LLVM's own testing/debugging
purposes.  They are likely to change both in spelling and meaning.

WARNING: This patch is knowingly incorrect in some cornercases.  We need, and
do not yet provide, a mechanism to selective enable/disable the padding.
Conversation on this will continue in parellel with work on extending this
infrastructure to support prefix padding.

The goal here is to have the assembler align specific instructions such that
they neither cross or end at a 32 byte boundary.  The impacted instructions are:
a. Conditional jump.
b. Fused conditional jump.
c. Unconditional jump.
d. Indirect jump.
e. Ret.
f. Call.

The new options for llvm-mc are:
    -x86-align-branch-boundary=NUM aligns branches within NUM byte boundary.
    -x86-align-branch=TYPE[+TYPE...] specifies types of branches to align.

A new MCFragment type, MCBoundaryAlignFragment, is added, which may emit
NOP to align the fused/unfused branch.

alignBranchesBegin inserts MCBoundaryAlignFragment before instructions,
alignBranchesEnd marks the end of the branch to be aligned,
relaxBoundaryAlign grows or shrinks sizes of NOP to align the target branch.

Nop padding is disabled when the instruction may be rewritten by the linker,
such as TLS Call.

Process Note: I am landing a patch by skan as it has been LGTMed, and
continuing to iterate on the review is simply slowing us down at this point.
We can and will continue to iterate in tree.

Patch By: skan
Differential Revision: https://reviews.llvm.org/D70157

This adds dummy files to the test resource directory used by the Clang
driver tests.

rdar://problem/58118584

  static void *ifunc(void) __attribute__((ifunc("resolver")));
  void foo() { ifunc(); }

The relocation produced by the ifunc() call:

1. gcc -msecure-plt -fPIC => R_PPC_PLTREL24 r_addend=0x8000
2. gcc -msecure-plt -PIE => R_PPC_PLTREL24 r_addend=0x8000
3. clang -msecure-plt -fPIC => R_PPC_PLTREL24 r_addend=0x8000
4. clang -msecure-plt -fPIE => R_PPC_REL24

4 is incorrect. The R_PPC_REL24 needs a call stub due to ifunc. If this
relocation is mixed with other R_PPC_PLTREL24(r_addend=0x8000) in a
function, both GNU ld and lld (after D71621 fix) may produce a wrong
result.

This patch fixes 4 to use R_PPC_PLTREL24, which matches GCC.
Both GNU ld and lld (after D71621) will be happy.

Reviewed By: sfertile

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

The setcc operands are copied into LHS and RHS variables at the top of the function. We also capture the condition code.

A later piece of code swaps the operands and changing the CC variable as part of a canonicalization to make some other checks simpler. But we might not make the transform we canonicalized for. So we continue on through the function where we can use the swapped LHS/RHS variables and access the original condition code operand instead of the modified CC variable. This leads to a setcc being created with the original condition code, but with swapped operands.

To mitigate this, this patch does a couple things. The LHS/RHS/CC variables are made const to keep them from being modified like this again. The transform that needs the swap now uses temporary copies of the variables. And the transform that used the original condition code operand has been altered to use the CC variable we cached originally. Either of these changes are enough to fix the issue, but doing both to make this code very safe.

I also considered rewriting the swap code in some way to check both permutations without explicitly swapping or needing temporary variables, but held off on that.

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

This implements a very elementary Lua script interpreter. It supports
running a single command as well as running interactively. It uses
editline if available. It's still missing a bunch of stuff though. Some
things that I intentionally ingored for now are that I/O isn't properly
hooked up (so every print goes to stdout) and the non-editline support
which is not handling a bunch of corner cases. The latter is a matter of
reusing existing code in the Python interpreter.

Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html

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

Previously, if the current function had a nonstandard stack layout/ABI, and had a valid
data pointer in the location where the return address is usually located, data corruption
would occur when the breakpoint was written. This could lead to an incorrectly reported
crash or silent corruption of the program's state. Now, if the above check fails, the command safely aborts.

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

Because the name of a direct method must be agreed upon by the caller
and the implementation, certain bad practices that one can get away with
when using dynamism are fatal with direct methods.

To avoid really weird and unscruttable linker error, tighten the
front-end error reporting.

Rule 1:
  Direct methods can only have at most one declaration in an @interface
  container. Any redeclaration is strictly forbidden.

  Today some amount of redeclaration is tolerated between the main
  interface and categories for dynamic methods, but we can't have that.

Rule 2:
  Direct method implementations can only be declared in a matching
  @interface container: when implemented in the primary @implementation
  then the declaration must be in the primary @interface or an
  extension, and when implemented in a category, the declaration must be
  in the @interface for the same category.

Also fix another issue with ObjCMethod::getCanonicalDecl(): when an
implementation lives in the primary @interface, then its canonical
declaration can be in any extension, even when it's not an accessor.

Add Sema tests to cover the new errors, and CG tests to beef up testing
around function names for categories and extensions.

Radar-Id: <rdar://problem/58054563>

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

    TracingStarted gets called in the Thread constructor, which means you can't
    call a virtual method of the class.  So delay setting up the m_register_values
    till you need them.  NFC as lldb just crashes if you don't do this.

    The thread tracing is an only occasionally useful feature, and it only sort
    of works.  I'm not adding tests etc. at this point, I'm just poking at it a
    bit.  If I get it working better I'll write tests and so forth.

Summary: Replace the integer immediate intrisics with splat vector variants so they can be applied as optimizations for the C/C++ intrinsics.

Reviewers: sdesmalen, huntergr, rengolin, efriedma, c-rhodes, mgudim, kmclaughlin

Subscribers: tschuett, kristof.beyls, hiraditya, rkruppe, psnobl, llvm-commits, amehsan

Tags: #llvm

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

The SELR(Mux) instructions can be converted to two-address form as LOCR(Mux)
instructions whenever one of the sources are the same reg as dest. By adding
this mapping in getTwoOperandOpcode(), we get:

- Two-address hints in getRegAllocationHints() for select register
  instructions.

- No need anymore for special handling in SystemZShortenInst.cpp -
  shortenSelect() removed.

The two-address hints are now added before the GRX32 hints, which should be
preferred.

Review: Ulrich Weigand
https://reviews.llvm.org/D68870

We have a central header for all these methods so we can
just use those for creating ClangASTContexts.

Summary:
With -gdwarf-5 local variable locations are emitted as DW_FORM_loclistx
form instead of the regular DW_FORM_sec_offset. Teach
DWARFDie::getLocations to understand the new format and use it in
llvm-symbolizer "FRAME" command.

Reviewers: pcc, jdoerfert

Subscribers: srhines, aprantl, hiraditya, rupprecht, llvm-commits

Tags: #llvm

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

This reverts commits 7e18aeba (D70376) 21fbd558 (D69914) due to increased memory usage.

It was recently discovered that the handling of CC values was actually broken
since overflow was not properly handled ('nsw' flag not checked for).

Add and sub instructions now have a new target specific instruction flag
named SystemZII::CCIfNoSignedWrap. It means that the CC result can be used
instead of a compare with 0, but only if the instruction has the 'nsw' flag
set.

This patch also adds the improvements of conversion to logical instructions
and the analyzing of add with immediates, to be able to eliminate more
compares.

Review: Ulrich Weigand
https://reviews.llvm.org/D66868

This reverts commit bbcf1c34.

We already pass a Decl here and the additional ASTContext needs to
match the Decl. We might as well just pass the Decl and then extract
the ASTContext from that.

[clang-format] C# formatting a class with inheritance followed by an attribute specifier assume its a braces initializer

Summary:
https://bugs.llvm.org/show_bug.cgi?id=44340

The rule that prevents `... {} [[....]]`  being treated as a braced initializer for C++ causes problems for C# with attributes, causing it to be incorrectly classified and then messing up the subsequent formatting. (see bug for details of formatting)

Reviewers: mitchell-stellar, klimek, sammccall

Reviewed By: mitchell-stellar

Subscribers: cfe-commits

Tags: #clang-format, #clang

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

Introduce a new %run_nomprotect substitution to run tests that do not
work with MPROTECT enabled.  This uses paxctl via a wrapper on NetBSD,
and evaluates to plain %run on other systems.

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

Add NetBSD to the same feature list as Fuchsia since it matches
in available features, effectively enabling aligned_alloc(),
timespec_get() and C11 features.  Remove now-duplicate declaration
of quick_exit() support.

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

The variable is unused.

PR44321:
https://bugs.llvm.org/show_bug.cgi?id=44321

The buildbot which necessitated this is fixed.

Summary:
In order to implement `malloc_{enable|disable}` we were just disabling
(or really locking) the Primary and the Secondary. That meant that
allocations could still be serviced from the TSD as long as the cache
wouldn't have to be filled from the Primary.

This wasn't working out for Android tests, so this change implements
registry disabling (eg: locking) so that `getTSDAndLock` doesn't
return a TSD if the allocator is disabled. This also means that the
Primary doesn't have to be disabled in this situation.

For the Shared Registry, we loop through all the TSDs and lock them.
For the Exclusive Registry, we add a `Disabled` boolean to the Registry
that forces `getTSDAndLock` to use the Fallback TSD instead of the
thread local one. Disabling the Registry is then done by locking the
Fallback TSD and setting the boolean in question (I don't think this
needed an atomic variable but I might be wrong).

I clang-formatted the whole thing as usual hence the couple of extra
whiteline changes in this CL.

Reviewers: cferris, pcc, hctim, morehouse, eugenis

Subscribers: jfb, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

The back-end currently has special DAGCombine code to detect
cases where two floating-point extend or truncate operations
can be combined into a single vector operation.

This patch extends that support to also handle strict FP operations.

Note that currently only the case where both operations have the
same input chain are supported.  This already suffices to cover
the common case where the operations result from scalarizing a
non-legal vector type.  More general cases can be supported in
the future.

In general SVE intrinsics are considered predicated and merging
with everything else having suitable decoration.  For predicated
zeroing operations (like the predicate logical instructions) we
use the "_z" suffix.  After this change all intrinsics use their
expected names (i.e. orr instead of or and eor instead of xor).

I've removed intrinsics and patterns for condition code setting
instructions as that data is not returned as part of the intrinsic.
The expectation is to ask for a cc flag explicitly.

For example:
  a = and_z(pg, p1, p2)
  cc = ptest_<flag>(pg, a)

With the code generator expected to use "s" variants of instructions
when available.

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