MipsCodeEmitter.cpp.

llvm-svn: 158701

Note that this is mostly a structural patch that handles the change from the old
spelling style to the new one. One consequence of this is that all AT_foo_bar
enum values have changed to not be based off of the first spelling, but rather
off of the class name, so they are now AT_FooBar and the like (a straw poll on
IRC showed support for this). Apologies for code churn.

Most attributes have GNU spellings as a temporary solution until everything else
is sorted out (such as a Keyword spelling, which I intend to add if someone else
doesn't beat me to it). This is definitely a WIP.

I've also killed BaseCheckAttr since it was unused, and I had to go through
every attribute anyway.

llvm-svn: 158700

It turns out SourceManager treating the "one-past-the-end" location as invalid,
but then failing to set the invalid flag properly.

llvm-svn: 158699

PPC will now generate STWUX and friends.

llvm-svn: 158698

ObjCInterfaceDec::lookupInstanceMethod to make sure we check categories as well
and update related tests.

rdar://11695288

llvm-svn: 158697

llvm-svn: 158696

llvm-svn: 158695

option. On the driver, check if we are using libraries from gcc 4.7 or newer
and if so pass -fuse-init-array to the frontend.
The crtbegin*.o files in gcc 4.7 no longer call the constructors listed in
.ctors, so we have to use .init_array.

llvm-svn: 158694

lldb confused by single quote in executable path

Also add a test case.

llvm-svn: 158693

TargetLoweringObjectFileELF. Use this to support it on X86. Unlike ARM,
on X86 it is not easy to find out if .init_array should be used or not, so
the decision is made via TargetOptions and defaults to off.

Add a command line option to llc that enables it.

llvm-svn: 158692

because it expects a reference and receives a non-l-value.

For example, given:

  int foo(int &);
  template<int x> void b() { foo(x); }

clang will now print "expects an l-value for 1st argument" instead of
"no known conversion from 'int' to 'int &' for 1st argument". The change
in wording (and associated code to detect the case) was prompted by
comment #5 in PR3104, and should be the last bit of work needed for the
bug.

llvm-svn: 158691

the compiler predefines buffer.  These are essentially part of
the Objective-C language.

llvm-svn: 158690

Per post-commit review, it's not appropriate to use ExtWarn in C++, because
we can't prove that the inline function will actually be defined in more than
one place (and thus we can't prove that this violates the ODR).

This removes the warning entirely from uses in the main source file in C++.

llvm-svn: 158689

revert r158660, since Chris has some issues with this patch (namely using code to reprent information only used by the compiler)

Original commit msg:
add the 'alloc' metadata node to represent the size of offset of buffers pointed to by pointers.
This metadata can be attached to any instruction returning a pointer

llvm-svn: 158688

llvm-svn: 158687

llvm-svn: 158686

Based on review discussion of r158638 with Chandler Carruth, Tobias von Koch, and Duncan Sands and a -Wmaybe-uninitialized warning from GCC.

llvm-svn: 158685

This change is to be enabled in clang.

rdar://9877866

llvm-svn: 158684

This includes treating anonymous namespaces like internal linkage, and allowing
const variables to be used even if internal. The whole thing's been broken out
into a separate function to avoid nested ifs.

llvm-svn: 158683

diag-build acts as a wrapper for 'diagtool show-enabled', in the same way
that scan-build acts as a wrapper for the static analyzer. The common case is
simple: use 'diag-build make' or 'diag-build xcodebuild' to list the warnings
enabled for the first compilation command we see. Other build systems require
you to manually specify "dry-run" and "use $CC and $CXX"; if there is a build
system you are interested in, please add it to the switch statement.

diag-build is fairly stupid right now, but it serves its basic purpose.
Hopefully it can grow to meet any additional requirements.

llvm-svn: 158682

llvm-svn: 158681

This patch changes the type used to hold the FU bitset from unsigned to uint64_t.
This will be needed for some upcoming PowerPC itineraries.

llvm-svn: 158679

llvm-svn: 158678

Patch by Mikael Lyngvig!

llvm-svn: 158677

This simplifies the code a little bit, since these functions all took a
SourceManager parameter and called a bunch of methods on it, and makes
the functions available to other users.

llvm-svn: 158676

llvm-svn: 158675

The NOP, WFE, WFI, SEV and YIELD instructions are all hints w/
a different immediate value in bits [7,0]. Define a generic HINT
instruction and refactor NOP, WFI, WFI, SEV and YIELD to be
assembly aliases of that.

rdar://11600518

llvm-svn: 158674

When returning a 'cannot match due to missing CPU features' error code,
if there are multiple potential matches with different feature sets,
return the smallest set of missing features from the alternatives as
that's most likely to be the one that's desired.

llvm-svn: 158673

llvm-svn: 158670

This exploits the relative order of the arguments and/or checks already
made in the functions.

llvm-svn: 158669

* Escaped "::" where needed to prevent Doxygen trying to make links;
* Updated one mention of C++0x to refer to C++11;
* Fixed a \brief summary to make it somewhat concise.

llvm-svn: 158667

This handles the very common case of people writing inline functions in their
main source files and not tagging them as inline. These cases should still
behave as the user intended. (The diagnostic is still emitted as an extension.)

I'm reworking this code anyway to account for C++'s equivalent restriction in
[basic.def.odr]p6, but this should get some bots back to green.

llvm-svn: 158666

// rdar://11676972

llvm-svn: 158665

Patch by Nikola Smiljanic!

llvm-svn: 158664

crash on invalid function decl with alloc_size attribute

llvm-svn: 158663

alloc_size attribute: there's nothing wrong with alloc_size(1,1). It just means the function allocates x^2 bytes. GCC also accepts this syntax

llvm-svn: 158662

Now, as long as the 'Namespaces' variable is correct inside Attr.td, the
generated code will correctly admit a C++11 attribute only when it has the
appropriate namespace(s).

llvm-svn: 158661

This metadata can be attached to any instruction returning a pointer

llvm-svn: 158660

when a compile time constant is known.  This occurs when implicitly zero 
extending function arguments from 16 bits to 32 bits.  The 8 bit case doesn't
need to be handled, as the 8 bit constants are encoded directly, thereby
not needing a separate load instruction to form the constant into a register.

<rdar://problem/11481151>

llvm-svn: 158659

llvm-svn: 158658