llvm-svn: 285997

llvm-svn: 285996

This reverts commit r285939 and r285948.  These broke some conformance tests.

llvm-svn: 285995

llvm-svn: 285994

This introduces big-endian support in imath and resolves
http://llvm.org/PR24632.

llvm-svn: 285993

The mock server was listening for only one packet (I forgot to put a loop around
it), which caused the client to stall in debug builds, as the timeout there is
1000 seconds. In case of a release builds the test would just silently succeed as
the tested function does not check or report errors (which should be fixed).

This fixes the test by adding the server loop. Since the test was taking quite a
long time now (8s), I have added a parameter to control the amount of data sent
(default 4MB), and call it with a smaller value in the test, to make the test run
faster.

llvm-svn: 285992

Author: A Trick
llvm-svn: 285991

SequenceNumberManager.

Sadly, we don't have any unittests for this class because it is
a private class. Since it seems to have a nice isolated and testable
interface, it'd be great to extract it to a detail namespace and write
unit tests for it as then we could catch issues. I'll probably pester
Lang about that or some alternative refactoring.

This was noticed by PVS-Studio.

llvm-svn: 285990

insufficient to populate the expected struct. Prior to this we already
bailed out of the routine when this situation comes up, so none of this
code had any effect.

If someone wants to bring it back to handle these cases, fixing the
earlier conditions and adding the necessary test cases that actually
exercises it, they can always revert this and go from there.

Both of these were noticed by PVS-Studio due to the identical (dead)
condition.

llvm-svn: 285989

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