Type legalization can zero-extend the elements of the build_vector node, so,
for example, we may have an <8 x i8> with i32 elements of value 255. That
should return 'true' for the vector being all ones.

llvm-svn: 153203

The getARMTargetCPU and getLLVMArchSuffixForARM functions exist in both
Toolchain.cpp and Tools.cpp.  This stuff needs a thorough overhaul.  In the
meantime, this patch at least makes them consistent.  One version had been
converted to use StringSwitch, and the other version had new Cortex M-series
processors added.

llvm-svn: 153202

use QualType contents unchecked.

llvm-svn: 153201

c-mode to match behavior with void functions in c. Issue
warning with -pedantic. // rdar://11069896

llvm-svn: 153200

relocations (LLVM revision 153147).  Now when
we report section locations in the target process,
LLVM will apply both those relocations whose
targets are in that section and those relocations
which reside in that section and point to other
sections.

llvm-svn: 153199

On Darwin the architecture and the corresponding Mach-O slice is typically
specified with -arch.  If not, it defaults to the current host architecture.
Do not use -mcpu to override the -arch value.  This is only an issue when
people need to use specialized code for a non-default CPU (hopefully guarded
by run-time checks to detect the current processor).  The -mcpu option is
still used for the -target-cpu option to clang, but this patch causes it to
not be used to set the architecture in the target triple.

llvm-svn: 153197

pointer field declarations in several meta-data.
// rdar://11079898

llvm-svn: 153196

llvm-svn: 153195

It appears that the standard accidentally removed the default constructor for error_category.  I'm putting it back in.  This fixes http://llvm.org/bugs/show_bug.cgi?id=12321.

llvm-svn: 153194

llvm-svn: 153193

pointer field declarations in several meta-data.
// rdar://11079898

llvm-svn: 153192

llvm-svn: 153190

llvm-svn: 153189

llvm-svn: 153188

llvm-svn: 153187

llvm-svn: 153186

llvm-svn: 153185

llvm-svn: 153184

llvm-svn: 153183

llvm-svn: 153182

llvm-svn: 153180

llvm-svn: 153179

llvm-svn: 153178

At the moment, asan internal Printf() uses %l modifier for printing
values of size_t and related types. This works, because we control
both the implementation of Printf and all its uses, but can be a
little misleading.

This change adds support for %z to Printf(). All callers that print
sizes and pointers as integers are switched to %zu / %zx.

llvm-svn: 153177

not attched to a basic block or function. There are conservatively
correct answers in these cases, and this makes the analysis more useful
in contexts where we have a partially formed bit of IR.

I don't have any way to test this directly... suggestions welcome here,
but I'm not seeing anything sadly. I only found this using a subsequent
patch to the inliner which runs instsimplify on partially inlined
instructions, and even then only on a quite large program. I never got
a reasonable testcase out of it, and anything I do get is likely to be
quite fragile due to requiring an interaction of two different passes,
and the only result being a segfault if it goes wrong.

llvm-svn: 153176

llvm-svn: 153175

Adds /usr/lib/debug early to list, as some systems (debian) have unstripped libs in there
Adds /lib/i386-linux-gnu for systems that does multiarch (debian)

llvm-svn: 153174

get_test_binary is a helper method, not a test, make sure nosetests
doesn't pick it up as a test.

llvm-svn: 153173

lit/TestRunner.py: [Win32] Rework WinWaitReleased() again! "win32file" from Python Win32 Extensions.

We can simply confirm the handle released to open it with EXCLUSIVE. Attempting renaming was bad.

Disable win32file at ImportError. Thanks to Francois to let me know.

FIXME: Could we report warning or notification if win32file were not found?
llvm-svn: 153172

Remaining "uncategorized" functions have been organized into their
proper place in the hierarchy. Some functions were moved around so
groups are defined together.

No code changes were made.

llvm-svn: 153169

in vtable layout where virtual methods inherited from virtual bases
could be assigned the same vcall adjustment slot if they shared
a name and parameter signature but differed in their
cv-qualification.  The code was already trying to handle this
case, but unfortunately used the ordinary type qualifiers
(which are always empty here) instead of the method qualifiers.
This seems like something that the API should discourage, but
I don't know how to carry that principle out in this instance.

Eliminate this function's need for an ASTContext while we're at it.

This bug affects the ABI, and fixing it brings us into accord with
the Itanium ABI (and GCC's implementation of it), but, obviously,
technically breaks full compatibility with previous releases of Clang.
Just letting you know.

llvm-svn: 153168

llvm-svn: 153167

the invalid cases. At least 16bit operand in 64bit mode is currently not
rejected in the parser.

llvm-svn: 153166

llvm-svn: 153165

the migration to ModuleSpec objects this broke and is now fixed.

Also fixed a case in the darwin kernel dynamic loader where we just need to
trust the load address of the kernel if we can't read it from memory.

llvm-svn: 153164

llvm-svn: 153163

llvm-svn: 153162

llvm-svn: 153161

llvm-svn: 153160

llvm-svn: 153159