llvm-svn: 153698

LLVM intrinsics for.

I have an implementation of these functions, which wants to go in a libgcc_s
equivalent in compiler-rt.  It's currently here:

http://people.freebsd.org/~theraven/atomic.c

It will be committed to compiler-rt as soon as I work out where would be a
sensible place to put it...

llvm-svn: 153666

llvm-svn: 153660

in the property debug info. Any more isn't necessary after all.

rdar://11144023

llvm-svn: 153659

llvm-svn: 153658

    http://llvm.org/docs/SourceLevelDebugging.html#objcproperty

    including type and DECL. Expand the getter and setter names
    into the fully qualified names.

    rdar://11144023

llvm-svn: 153640

a complete object, the memcpy needs to use the data size of
the structure instead of its sizeof() value.  Fixes PR12204.

llvm-svn: 153613

llvm-svn: 153578

flag as GCC uses: -fstrict-enums). There is a *lot* of code making
unwarranted assumptions about the underlying type of enums, and it
doesn't seem entirely reasonable to eagerly break all of it.

Much more importantly, the current state of affairs is *very* good at
optimizing based upon this information, which causes failures that are
very distant from the actual enum. Before we push for enabling this by
default, I think we need to implement -fcatch-undefined-behavior support
for instrumenting and trapping whenever we store or load a value outside
of the range. That way we can track down the misbehaving code very
quickly.

I discussed this with Rafael, and currently the only important cases he
is aware of are the bool range-based optimizations which are staying
hard enabled. We've not seen any issue with those either, and they are
much more important for performance.

llvm-svn: 153550

llvm-svn: 153447

llvm-svn: 153389

Thanks to NAKAMURA Takumi for finding it!

llvm-svn: 153383

Revert r153360 (and r153380), "Second part of PR12251. Produce the range metadata in clang for booleans and".

For i686 targets (eg. cygwin), I saw "Range must not be empty!" in verifier.

It produces (i32)[0x80000000:0x80000000) from (uint64_t)[0xFFFFFFFF80000000ULL:0x0000000080000000ULL), for signed i32 on MDNode::Range.

llvm-svn: 153382

c++ enums.

llvm-svn: 153360

llvm-svn: 153356

cast the value to x86_mmx. This gives the ASM string the correct call signature.
<rdar://problem/10919182>

llvm-svn: 153290

Make sure we correctly set the alignment for vector loads and stores associated with vector element lvalues.  Patch by Kevin Schoedel (with some minor modifications by me).

llvm-svn: 153285

llvm-svn: 153149

Fixes PR12284. The test case only triggered under asan/valgrind, but it's better than nothing.

llvm-svn: 153120

TrackingVH notices when it gets RAUW'd. Fixes PR12305 and PR12315.

llvm-svn: 153115

llvm-svn: 153090

% is a common character in IR so we'd crash on almost any malformed IR. The
diagnostic formatter expects a formatting directive when it sees an unescaped %.

llvm-svn: 152956

store to 1. This allows code-gen to select a more appropriate alignment. If left
to zero, an alignment greater than the alignment of the pointer may be selected,
causing code-gen to use instructions which require an alignment greater than the
pointer guarantees.
<rdar://problem/11043589>

llvm-svn: 152951

Don't try to create "store atomic" instructions of non-integer types; they aren't supported at the moment.  PR12040.

llvm-svn: 152891

When a variable has a specified asm name, but isn't using the register storage class, the asm name doesn't specify a register. PR12244.

llvm-svn: 152873

Patch by Silviu Baranga!

llvm-svn: 152788

-fno-inline-functions.

This behaves much like -fno-inline in gcc, but based on a discussion with 
Daniel it was decided that -fno-inline-functions should subsume -fno-inline.
Please speak up if you object.  The -fno-inline flag remains ignored.
Final part of rdar://10972766

llvm-svn: 152754

args.

Fixes rdar://11042577

llvm-svn: 152691

function templates as well.

A future commit will mangle the added name with the template args
like classes are mangled.

Fixes rdar://10986010

llvm-svn: 152683

ObjCInterfaceDecl::getReferencedProtocols(), because the iterators are safe to use
even if the caller did not check that the interface is a definition.

llvm-svn: 152597

The member variable is always "LangOpts" and the member function is always "getLangOpts".

Reviewed by Chris Lattner

llvm-svn: 152536

Renamed methods caseBegin, caseEnd and caseDefault with case_begin, case_end, and case_default.
Added some notes relative to case iterators.

llvm-svn: 152533

llvm-svn: 152503

track whether the referenced declaration comes from an enclosing
local context.  I'm amenable to suggestions about the exact meaning
of this bit.

llvm-svn: 152491

we correctly emit loads of BlockDeclRefExprs even when they
don't qualify as ODR-uses.  I think I'm adequately convinced
that BlockDeclRefExpr can die.

llvm-svn: 152479

 - We do this when it is easy to determine that the backend will pass them on
   the stack properly by itself.

Currently LLVM codegen is really bad in some cases with byval, for example, on
the test case here (which is derived from Sema code, which likes to pass
SourceLocations around)::

  struct s47 { unsigned a; };
  void f47(int,int,int,int,int,int,struct s47);
  void test47(int a, struct s47 b) { f47(a, a, a, a, a, a, b); }

we used to emit code like this::

  ...
  movl	%esi, -8(%rbp)
  movl	-8(%rbp), %ecx
  movl	%ecx, (%rsp)
  ...

to handle moving the struct onto the stack, which is just appalling.

Now we generate::

  movl	%esi, (%rsp)

which seems better, no?

llvm-svn: 152462

Make sure we update the static local decl address map when we are forced to rebuild a global because of the initializer.  <rdar://problem/10957867>.

llvm-svn: 152372

Make sure constant emission handles initializer lists with strings correctly.  Part of <rdar://problem/10957867>.

llvm-svn: 152370

 - This function is not at all free; pass it around along some hot paths instead
   of recomputing it deep inside various VarDecl methods.

llvm-svn: 152363

HandleCXXStaticMemberVarInstantiation. Suggested by Argyrios.

llvm-svn: 152320