instruction.

This avoids dereferencing null in the debug logging if the instruction
was not in fact a return instruction. This potential bug was found by
PVS-Studio.

This actually fixes the last of the "dereferenced a pointer before
checking it for null" reports in the recent PVS-Studio run. However,
there are quite a few reports of this nature that I did not do anything
to fix because they are pretty glaring false positives. They usually
took the form of quite clear correlated checks or a check made in
a separate function. I've even added asserts anywhere this correlation
wasn't pretty obvious and fundamental to the code.

llvm-svn: 285988

of which that is hidden inside a separate function call) and helpfully
before building expensive transaction infrastructure. This will avoid
crashing when running CGP in a generic mode if we ever managed to hit
this case.

Note that I spent some time looking at alternatives. CGP is actually
used without a TM or TLI in order to do some target-independent testing.
Further, all of the neighboring optimization techniques actually have
some paths that are effective even in the absence of TLI so this seemed
the correct scope at which to check and bypass logic. It still isn't
clear that long-term support for missing TM/TLI is the right
cost/benefit tradeoff for CGP -- we seem to get relatively little for it
and the code is just littered with checks (and assumptions which
I suspect are still missing some checks).

This at least fixes the potential bug in this code spotted by
PVS-Studio, so we've got that going for us. ;]

llvm-svn: 285987

CXCursor_FriendDecl was added in r285984

llvm-svn: 285986

which guarantee pointers are not null. These all seem to have useful
properties and correlations to document, in one case we even had it in
a comment but now it will also be an assert.

This should prevent PVS-Studio from incorrectly claiming that there are
a bunch of potential bugs here. But I feel really strongly that the
PVS-Studio warnings that pointed at this code have a far too high
false-positive rate to be entirely useful. These are just places where
there did seem to be a useful invariant to document and verify with an
assert. Several other places in the code were already correct and
already have perfectly clear code documenting and validating their
invariants, but still ran afoul of PVS-Studio.

llvm-svn: 285985

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

llvm-svn: 285984

The exact same test guards entry into the loop in which this test
occurs, and there is nothing inside the loop that assigns to the
variable, so it has already been checked for null.

This was flagged by PVS-Studio as well, but the report is actually wrong
-- this is not a case where we dereference a variable prior to testing
it for null, this is a case where we have a redundant test for null
after we already performed the exact same test.

llvm-svn: 285983

corresponds to another argument being valid.

This makes it clear that the code is correct despite the PVS-Studio
report that a pointer might be dereferenced prior to being checked for
whether it is null. It likely is also enough for static analyzers to not
flag the code.

llvm-svn: 285982

Present tests for the functionality provided by command lime option
`-ast-print` check only absence of crash. This change tries to make
testing better, - the output produced by the compiler is compiled again
with option `-print-ast` and both outputs are compared. Such test at
least checks that the output is valid code. This change fixes only the
test for pure C.

This is recommit of r285882.

llvm-svn: 285981

dereferenced the pointer at this point, and these routines are
exclusively called after the parser encounters a code completion token.
Other code completion routines called at that point do not check for
null either, so this is clearly the current invariant expected in the
code.

This fixes another PVS-Studio found issue.

llvm-svn: 285980

Output generated by option '-ast-print' must not contains enum
base type specifications if source language does not include C++11.

llvm-svn: 285979

llvm-svn: 285978

of clang.

llvm-svn: 285977

llvm-svn: 285976

llvm-svn: 285975

the process exists.

I also added some tests that crash before this fix, and work correctly after.

<rdar://problem/29083321>

llvm-svn: 285974

Summary:
Instead of keeping track of TODOs for lit in a file checked into source
control, use LLVM's bug tracker. The TODOs have been migrated to the
following bugs:

* https://llvm.org/bugs/show_bug.cgi?id=30666
* https://llvm.org/bugs/show_bug.cgi?id=30667
* https://llvm.org/bugs/show_bug.cgi?id=30668
* https://llvm.org/bugs/show_bug.cgi?id=30669
* https://llvm.org/bugs/show_bug.cgi?id=30670
* https://llvm.org/bugs/show_bug.cgi?id=30671

Reviewers: ddunbar, beanz, echristo, delcypher

Subscribers: llvm-commits, mehdi_amini

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

llvm-svn: 285973

behind the test that the MachineModuleInfo analysis was
actually available and can be used.

While the MachO bits may well be reasonable to assume in the darwin
assembly printer, the analysis isn't constructively guaranteed anywhere
I could find so it seems safest to avoid crashing here.

This issue was found with PVS-Studio. Pretty sure the Clang Static
Anaylzer flags similar issues but we've probably never pointed it at
this code effectively.

llvm-svn: 285972

llvm-svn: 285971

This fixes a mismatch between the declared error_type and the type used with
the placement new that initializes the field.

Patch by Yichao Yu.

llvm-svn: 285970

Summary: ARMv6m supports dmb etc fench instructions but not ldrex/strex etc. So for some atomic load/store, LLVM should inline instructions instead of lowering to __sync_ calls.

Reviewers: rengolin, efriedma, t.p.northover, jmolloy

Subscribers: efriedma, aemerson, llvm-commits

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

llvm-svn: 285969

If multi-threading is disabled, parallel_for_each will automatically
fall back to std::for_each, so we don't have to do that ourselves.

llvm-svn: 285968

in llvm-objdump for Mach-O files add the printing of the
ARM_THREAD_STATE64 in the same format as
otool-classic(1) on darwin.

To do this the 64-bit ARM general tread state
needed to be defined in include/llvm/Support/MachO.h .

rdar://28985800

llvm-svn: 285967

llvm-svn: 285966

This avoids duplicating the buffer in InputFile.

llvm-svn: 285965

Delete an empty line at the end of README.txt file.

llvm-svn: 285964

llvm-svn: 285962

All error checking now happens when the information is needed. The
only thing left is the minimum size of the buffer and that can be just
a precondition. I will add an ErrorOr create method in a followup
commit.

Also don't store a pointer to the Header, since it is just a trivial
cast.

llvm-svn: 285961

<rdar://problem/18616046>

llvm-svn: 285960

This implements the DWARF 5 DW_AT_export_symbols feature:
http://dwarfstd.org/ShowIssue.php?issue=141212.1

<rdar://problem/18616046>

llvm-svn: 285959

llvm-svn: 285958

Summary:
These functions currently require that the new closed interval has a length of
at least 2.  They also currently permit empty half-open intervals.  This patch
defines nonEmpty in each traits structure and uses it to correct the
implementations of setStart and setStop.

Reviewers: stoklund, chandlerc

Subscribers: llvm-commits

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

llvm-svn: 285957

llvm-svn: 285956

llvm-svn: 285955

  * if the base is produced by a series of derived-to-base conversions, check
    the expression inside them when looking for an expression with a known
    dynamic type
  * step past MaterializeTemporaryExprs when checking for a known dynamic type
  * when checking for a known dynamic type, treat all class prvalues as having
    a known dynamic type after skipping all relevant rvalue subobject
    adjustments
  * treat callees formed by pointer-to-member access for a non-reference member
    type like callees formed by member access.

llvm-svn: 285954

The buffer is already owned by the PDBFile for all of these APIs, so
don't pass it in separately.

llvm-svn: 285953

llvm-svn: 285952

Issue found by inspection.

llvm-svn: 285951

code, let's just assert that the DiagonsticEngine doesn't own the client
because our constructor took ownership of it and has a std::unique_ptr
that handles deleting it. This seems much more clear -- the release was
harmless but confusing as if there were some memory there it would have
leaked, and the reset was harmless but confusing as if there were some
memory there it would have been double-freed. But in both cases there
was nothing there.

llvm-svn: 285950

Previously, it didn't support the character class, so we couldn't
eliminate the use fo llvm::Regex. Now that it is supported, we
can remove compileGlobPattern, which converts a glob pattern to
a regex.

This patch contains optimization for exact/prefix/suffix matches.

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

llvm-svn: 285949

This file is unused as of r285939, but we need to keep it around
for bots that don't do full rebuilds.   We should be able to delete this
again in a few days.

llvm-svn: 285948