This fixes a test which exposed an ASan issue.
We assumed that a symbol's section number had a corresponding section
without performing validation.
llvm-svn: 263558
Commit f49839299a085505eb673544744b61d2d9cdd1db in glibc-2.14 changed the
locales to the currently required format. However, they were again changed in
commit 55bdd2866f23b28422d969060b3518909a12b100 which has been released in 2.17.
That leads to the current situation where Debian and e.g. CentOS 6 have the
pre-2.14 locales, for example Ubuntu 14.04 has pre-2.17 and CentOS 7 on the
other hand has the newest locales in glibc-2.17.
Differential Revision: http://reviews.llvm.org/D18187
llvm-svn: 263554
Summary:
This patch adds base support for codegen of the target directive on the NVPTX device.
Reviewers: ABataev
Differential Revision: http://reviews.llvm.org/D17877
llvm-svn: 263552
On OS X 10.11+, we have "automatic interceptors", so we don't need to use DYLD_INSERT_LIBRARIES when launching instrumented programs. However, non-instrumented programs that load TSan late (e.g. via dlopen) are currently broken, as TSan will still try to initialize, but the program will crash/hang at random places (because the interceptors don't work). This patch adds an explicit check that interceptors are working, and if not, it aborts and prints out an error message suggesting to explicitly use DYLD_INSERT_LIBRARIES.
Differential Revision: http://reviews.llvm.org/D18121
llvm-svn: 263551
Currently when an AST plugin is loaded it must then be enabled by passing
-plugin pluginname or -add-plugin pluginname to the -cc1 command line. This
patch adds a method to PluginASTAction which allows it to declare that the
action happens before, instead of, or after the main AST action, plus the
relevant changes to make the plugin action happen at that time automatically.
Differential Revision: http://reviews.llvm.org/D17959
llvm-svn: 263546
This fixes a recently reported a bug(https://llvm.org/bugs/show_bug.cgi?id=26790) relating to the clang expression evaluator no longer being able to resolve calls to
functions with arguments to typedefed anonymous structs, unions, or enums after a cleanup to the expression parsing code in r260768
This fixes the issue by attaching the tagged name to the original clang::TagDecl object when generating the typedef in lldb::ClangAstContext::CreateTypeDef.
This also fixes the issue for anonymous typedefs for non-struct types (unions and enums) where we have a tag name.
Author: Luke Drummond <luke.drummond@codeplay.com>
Differential Revision: http://reviews.llvm.org/D18099
llvm-svn: 263544
The load configuration directory is a structure whose size varies as the
OS gains additional functionality. To account for this, the structure's
layout begins with a size field; this allows loaders to know which
fields are available.
However, LLD hard-coded the sizes (112 bytes for 64-bit and 64 for
32-bit). This means that we might not inform the loader of all the
pertinent fields or we might claim that there are more fields than are
actually present.
To correctly account for this, the size field must be loaded from the
_load_config_used symbol.
N.B. The COFF spec is either wrong or out of date, the load
configuration directory is not correctly documented in the
specification: it omits the size field.
llvm-svn: 263543
The TLS directory has a different layout depending on the bitness of the
machine the image will run on. LLD would always use the 64-bit TLS
directory for the data directory entry instead of an appropriately sized
TLS directory.
llvm-svn: 263539
This mirrors:
commit https://llvm.org/svn/llvm-project/llvm/trunk@263462
Author: Michael Kuperstein <michael.kuperstein@gmail.com>
Date: Mon Mar 14 18:34:29 2016 +0000
[AliasSetTracker] Do not strip pointer casts when processing MemSetInst
and fixes the failure the above commit triggered in Polly.
llvm-svn: 263538
The PE TLS directory contains information about where the TLS data
resides in the image, what functions should be executed when threads are
created, etc.
llvm-svn: 263537
Switch gofrontend to using go.googlesource.com, and
update to 81eb6a3f425b2158c67ee32c0cc973a72ce9d6be.
There are various changes required to update to the
go 1.5 runtime:
typemap.go is changed to accommodate the change in representation for equal/hash algorithms, and the removal of the zero value/type.
CMakeLists.txt is updated to add the build tree to the package search path, so internal packages, which are not installed, are found.
various files changes due to removal of __go_new_nopointers; the same change as in D11863, but with NoUnwindAttribute added to the added runtime functions which are called with "callOnly".
minor cleanups in ssa.go while investigating issues with unwinding/panic handling.
Differential Revisision: http://reviews.llvm.org/D15188
llvm-svn: 263536
Summary:
LLVMGetTargetDataLayout was removed from the C API,
and then TargetMachine.TargetData was removed. Later,
LLVMCreateTargetMachineData was added to the C API,
and we now expose this via the Go API.
Reviewers: deadalnix, pcc
Subscribers: cierniak, llvm-commits, axw
Differential Revision: http://reviews.llvm.org/D18173
llvm-svn: 263530
Since the static getGlobalIdentifier and getGUID methods are now called
for global values other than functions, reflect that by moving these
methods to the GlobalValue class.
llvm-svn: 263524
It would be nice to have a longer-term plan for how to handle help for regular expression commands, since their syntax is highly irregular. I can see a few options (*), but for now this is a reasonable stop-gag measure for the most blatant regression.
(*) the simplest is, of course, to detect a regex command and inherit the syntax for any aliases thereof; it would be nice if this also didn't show the underlying regex command name when the alias is used
llvm-svn: 263523
In some places, like InstCombine, we resize a DenseMap to fit the elements
we intend to put in it, then insert those elements (to avoid continual
reallocations as it grows). But .resize(foo) doesn't actually do what
people think; it resizes to foo buckets (which is really an
implementation detail the user of DenseMap probably shouldn't care about),
not the space required to fit foo elements. DenseMap grows if 3/4 of its
buckets are full, so this actually causes one forced reallocation every
time instead of avoiding a reallocation.
This patch makes .resize(foo) do the intuitive thing: it grows to the size
necessary to fit foo elements without new allocations.
Also include a test to verify that .resize() actually does what we think it
does.
llvm-svn: 263522
This patch adds support for the MachO .alt_entry assembly directive, and uses
it for global aliases with non-zero GEP offsets. The alt_entry flag indicates
that a symbol should be layed out immediately after the preceding symbol.
Conceptually it introduces an alternate entry point for a function or data
structure. E.g.:
safe_foo:
// check preconditions for foo
.alt_entry fast_foo
fast_foo:
// body of foo, can assume preconditions.
The .alt_entry flag is also implicitly set on assembly aliases of the form:
a = b + C
where C is a non-zero constant, since these have the same effect as an
alt_entry symbol: they introduce a label that cannot be moved relative to the
preceding one. Setting the alt_entry flag on aliases of this form fixes
http://llvm.org/PR25381.
llvm-svn: 263521
Instead of running an explicit loop over `gc.relocate` calls hanging off
of a `gc.statepoint`, assert the validity of the type of the value being
relocated in `visitRelocate`.
llvm-svn: 263516
`MCSymbolRefExpr` variant kind for TLSCALL is prefixed with
_ARM_ since this is how it was originally implemented.
The X86_64 version is exactly the same so there's no reason
to create a new variant, we can just rename the existing
one to be machine-independent.
This generalization is the first step to implement support
for GNU2 TLS dialect in MC.
Differential Revision: http://reviews.llvm.org/D18160
llvm-svn: 263515
This is the companion to an LLVM patch that renamed the function index
data structures and files to use the more general module summary index.
(Recommit after fixing LLVM side to add back missed file)
llvm-svn: 263514
(Resubmitting after fixing missing file issue)
With the changes in r263275, there are now more than just functions in
the summary. Completed the renaming of data structures (started in
r263275) to reflect the wider scope. In particular, changed the
FunctionIndex* data structures to ModuleIndex*, and renamed related
variables and comments. Also renamed the files to reflect the changes.
A companion clang patch will immediately succeed this patch to reflect
this renaming.
llvm-svn: 263513
Summary:
Specifically, when we perform runtime loop unrolling of a loop that
contains a convergent op, we can only unroll k times, where k divides
the loop trip multiple.
Without this change, we'll happily unroll e.g. the following loop
for (int i = 0; i < N; ++i) {
if (i == 0) convergent_op();
foo();
}
into
int i = 0;
if (N % 2 == 1) {
convergent_op();
foo();
++i;
}
for (; i < N - 1; i += 2) {
if (i == 0) convergent_op();
foo();
foo();
}.
This is unsafe, because we've just added a control-flow dependency to
the convergent op in the prelude.
In general, runtime unrolling loops that contain convergent ops is safe
only if we don't have emit a prelude, which occurs when the unroll count
divides the trip multiple.
Reviewers: resistor
Subscribers: llvm-commits, mzolotukhin
Differential Revision: http://reviews.llvm.org/D17526
llvm-svn: 263509
These types are defined in ELFFile, so in order to use them, you have
to write ELFFile<ELFT>::SomeType. But there seems to be no reason to have
ELFFile have these types. This patch allows you to write ELFT::SomeType
instead.
This simplifies libObject users.
This is an example: http://reviews.llvm.org/D18129http://reviews.llvm.org/D18130
llvm-svn: 263504
Summary: This now try to reorder instructions in order to help create the optimizable pattern.
Reviewers: craig.topper, spatel, dexonsmith, Prazek, chandlerc, joker.eph, majnemer
Differential Revision: http://reviews.llvm.org/D16523
llvm-svn: 263503
David Majnemer