These patches cause us to miscompile and/or reject code with static
function-local variables in an extern-C context. Previously, we were
papering over this as long as the variables are within the same
translation unit, and had not seen any failures in the wild. We still
need a proper fix, which involves mangling static locals inside of an
extern-C block (as GCC already does), but this patch causes pretty
widespread regressions. Firefox, and many other applications no longer
build.

Lots of test cases have been posted to the list in response to this
commit, so there should be no problem reproducing the issues.

llvm-svn: 153768

other things which might mess with the variable's type.

llvm-svn: 153733

llvm-svn: 153728

is causing the gdb test failures on the bots.

llvm-svn: 153727

the case that the variable already exists.  Partly this is just
protection against people making crazy declarations with custom
asm labels or extern "C" names that intentionally collide with
the manglings of such variables, but the main reason is that we
can actually emit a static local variable twice with the
requirement that it match up.  There may be other cases with
(e.g.) the various nested functions, but the main exemplar is
with constructor variants, where we can be forced into
double-emitting the function body under certain circumstances
like (currently) the presence of virtual bases.

llvm-svn: 153723

inheritance.

llvm-svn: 153722

llvm-svn: 153721

ConstStructBuilder: fix offset math for base classes so it works correctly in general.  Found by inspection.

llvm-svn: 153720

property file/line rather than the @synthesize file/line. Avoids
some nasty confusing-ness with conflating the file from the scope
and the line from the original declaration.

Update a couple of testcases accordingly since I had to change
that we actually use the passed in location in EmitFunctionStart.

Fixes rdar://11026482

llvm-svn: 153714

section. A 'normal' string will go into the __TEXT,__const section, but this
isn't good for UTF16 strings. The __ustring section allows for coalescing, among
other niceties (such as allowing the linker to easily split up strings).

Instead of outputting the UTF16 string as a series of bytes, output it as a
series of shorts. The back-end will then nicely place the UTF16 string into the
correct section, because it's a mensch.
<rdar://problem/10655949>

llvm-svn: 153710

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