This reverts r328065.

I missed this one in r328085 and the bots were still failing.

llvm-svn: 328095

Removed a couple of methods from DispatchUnit.

llvm-svn: 328094

- constexpr is needed for out-of-class definition of the Type static
  member by some compilers
- MSVC is confused by the initialization of the static constexpr char[]
  member when it happens in a template specialization. Explicitly
  specifying the length of the array seems to be enough to help it
  figure things out.

llvm-svn: 328093

Add in a space when appending the export to the linker options. Without
the space the export is appended onto whatever the last link option
was, which might be a file.

llvm-svn: 328092

Due to recent kernel upgrades, these test case fail on PowerPC buildbots.
This is a known problem on affected kernels.

llvm-svn: 328091

Summary:
We have had at least three pieces of code (in DWARFAbbreviationDeclaration,
DWARFAcceleratorTable and DWARFDie) that have hand-rolled support for
dumping unknown dwarf enum values. While not terrible, they are a bit
distracting and enable small differences to creep in (Unknown_ffff vs.
Unknown_0xffff). I ended up needing to add a fourth place
(DWARFVerifier), so it seems it would be a good time to centralize.

This patch creates an alternative to the XXXString dumping functions in
the BinaryFormat library, which formats an unknown value as
DW_TYPE_unknown_1234, instead of just an empty string. It is based on
the formatv function, as that allows us to avoid materializing the
string for unknown values (and because this way I don't have to invent a
name for the new functions :P).

In this patch I add formatters for dwarf attributes, forms, tags, and
index attributes as these are the ones in use currently, but adding
other enums is straight-forward.

Reviewers: dblaikie, JDevlieghere, aprantl

Subscribers: llvm-commits

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

llvm-svn: 328090

As suggested by Pavel on lldb-commits. Originally I picked os.system
because it was so much more simple than the subprocess module, but that
no longer holds true after yesterday's hack in r328020. This is what it
should've been in the first place.

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

llvm-svn: 328089

The issue was that the ASTDumper was being passed a null pointer
(because we did not create any declaration for the operator==).  The
crash was in logging code, so it only manifested it self if you ran the
tests with logging enabled (like our bots do).

Given that this is logging code and the rest of the debugger is fine
with the declaration being null, I just make sure the logging code can
handle it as well. Right now I just do the null check in
ClangExpressionDeclMap, but if the ASTDumper class is meant to be a
debugging/logging aid, then it might be a good idea move the check
inside the class itself.

llvm-svn: 328088

+ Regenerate doc.

llvm-svn: 328087

llvm-svn: 328086

This reverts:
  r328072 "Move Compiler.h from Support to Demangler to fix layering."
  r328073 "Fix the actual user of DataTypes.h in llvm-c to avoid the circular dependency"

Failing bots:
  http://green.lab.llvm.org/green/job/clang-stage2-coverage-R/
  http://green.lab.llvm.org/green/job/clang-stage2-configure-Rlto/

llvm-svn: 328085

Summary:
When building the selection DAG we sometimes need to postpone
the handling of a dbg.value until the value it should refer to
is created. This is done by using the DanglingDebugInfoMap.
In the past this map has been limited to hold one dangling
dbg.value per value. This patch removes that restriction.

Reviewers: aprantl, rnk, probinson, vsk

Reviewed By: aprantl

Subscribers: Ka-Ka, llvm-commits, JDevlieghere

Tags: #debug-info

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

llvm-svn: 328084

- use more goodies from Makefile.rules to correctly build a 32-bit
binary.
- avoid hardcoding typeof(nil) in the test.

This should partially fix the linux bot. There is still one assertion
failure remaining, which I'll have to investigate separately, as I am
not experiencing it locally.

llvm-svn: 328083

328079 introduced a weak hook without default implementation.
This broke darwin build:
http://green.lab.llvm.org/green//job/clang-stage1-configure-RA/43731/consoleFull#-119213188149ba4694-19c4-4d7e-bec5-911270d8a58c

Provide default impl for the hook.

llvm-svn: 328082

Patch teaches LLD to hint user about -fdebug-types-section flag
if relocation overflow happens in debug section.

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

llvm-svn: 328081

Fix build bot after r328078 "llvm-readobj] - Teach llvm-readobj to dump .note.gnu.property sections."

BB was: http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/27058/steps/test/logs/stdio

llvm-svn: 328080

New API passes a callback function to the external symbolizer,
allowing it to add multiple frames to the traceback. Note that
the old interface API will be still supported until the clients
migrate to the new one.

Author: asmundak (Alexander Smundak)
Reviewed in: https://reviews.llvm.org/D44714

llvm-svn: 328079

NT_GNU_PROPERTY_TYPE_0 is a recently added type of .note.gnu.property
section specified in Linux Extensions to gABI.
(https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI)

Patch teach tool to print such notes properly.

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

llvm-svn: 328078

llvm-svn: 328077

[X86][Broadwell] Merge multiple InstrRW entries that map to the same SchedWriteRes group (NFCI) (PR35955)

llvm-svn: 328076

llvm-svn: 328075

It's only called from one place and is defined just above that use.

llvm-svn: 328074

(follow-up to r328065)

llvm-svn: 328073

Support depends on Demangle (Support/Unix/Signals.inc), so Demangle
including Support/Compiler.h created a circular dependency.

Leave a forwarding shim of Compiler.h because it makes more sense for
users (a deeper fix might involve splitting Support into lower and upper
Support - but that also sounds a bit weird/awkward) than thinking about
the dependency on the Demangler.

llvm-svn: 328072

llvm-svn: 328071

Summary:
This code previously had a SmallVector of std::pairs containing an unsigned and another SmallVector. The outer vector was using the unsigned effectively as a key to decide which SmallVector to add into. So each time something new needed to be added the out vector needed to be scanned. If it wasn't found a new entry needed to be added to be added. This sounds very much like a map, but the next loop iterates over the outer vector to get a deterministic order.

We can simplify this code greatly if use SmallMapVector instead. This uses more stack space since we now have a vector and a map, but the searching and creating new entries all happens behind the scenes. It should also make the search more efficient though usually there are only a few entries so that doesn't matter much.

We could probably get determinism by just using std::map which would iterate over the unsigned key, but that would generate different output from what we get with the current implementation.

Reviewers: RKSimon, dblaikie

Reviewed By: dblaikie

Subscribers: llvm-commits

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

llvm-svn: 328070

This reverts commit r328060 because a test that was inteded to run on
Windows but never ran before due to the missing config initialization
is now being executed and is failing.

llvm-svn: 328069

llvm-svn: 328068

It seems that the refactoring was causing a functional change and some warnings
have disappeared.

llvm-svn: 328067

r326249 wasn't quite enough because we often run out of inlining stack depth
limit and for that reason fail to see the atomics we're looking for.

Add a more straightforward false positive suppression that is based on the name
of the class. I.e. if we're releasing a pointer in a destructor of a "something
shared/intrusive/reference/counting something ptr/pointer something", then any
use-after-free or double-free that occurs later would likely be a false
positive.

rdar://problem/38013606

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

llvm-svn: 328066

Support depends on llvm-c (a few typedefs, macros, etc - Types.h,
Disassembler.h, and TargetMachine.h.

This could be done the other way - those macros/typedefs/etc could be
moved into Support and used from llvm-c instead. If someone feels that's
a better direction to go, happy to discuss it/try it out/etc.

llvm-svn: 328065

llvm-svn: 328064

[Analysis] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 328063

New tests should run the make syntax voodoo $@ and $<
instead of hardcoding the names. We should also document
how to write one, it's on my list.

llvm-svn: 328062

Also restrict to port 0 and 1 for SkylakeClient. It looks like the scheduler models don't account for client not having a full vector ALU on port 5 like server.

Fixes PR36808.

llvm-svn: 328061

Adding the config initialization to clang-tools-extra so that tests that
use REQUIRES, UNSUPPORTED, and XFAIL based on platform or target triple
work properly.

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

llvm-svn: 328060

llvm-svn: 328059

Most basic possible test for the logic used by LICM.

Also contains a speculative build fix for compiles which complain about a definition of a stuct K; followed by a declaration as class K;

llvm-svn: 328058

The tests compile after r328049

llvm-svn: 328057

(Currently showing without, will enable and check in diff to show impact)

llvm-svn: 328056