Adjust for LLVM name tweaks requested by Chandler.

llvm-svn: 154824

Propagate alignment on lvalues through EmitLValueForField. PR12395.

llvm-svn: 154789

Use MDBuilder to help with metadata creation.

llvm-svn: 154767

Rename "fpaccuracy" metadata to the more generic "fpmath". That's because I'm
thinking of generalizing it to be able to specify other freedoms beyond accuracy
(such as that NaN's don't have to be re

Rename "fpaccuracy" metadata to the more generic "fpmath". That's because I'm
thinking of generalizing it to be able to specify other freedoms beyond accuracy
(such as that NaN's don't have to be respected). I'd like the 3.1 release (the
first one with this metadata) to have the more generic name already rather than
having to auto-upgrade it in 3.2.

llvm-svn: 154745

show more ...

Step forward with supporting of ARM homogenous aggregates:
- Handle unions
- Handle C++ classes

llvm-svn: 154664

Implement __atomic_fetch_nand and __atomic_nand_fetch to complete our set of
GNU __atomic builtins.

llvm-svn: 154659

Implement the missing pieces needed to support libstdc++4.7's <atomic>:
__atomic_test_and_set, __atomic_clear, plus a pile of undocumented __GCC_*
predefined macros.

Implement library fallback for _

Implement the missing pieces needed to support libstdc++4.7's <atomic>:
__atomic_test_and_set, __atomic_clear, plus a pile of undocumented __GCC_*
predefined macros.

Implement library fallback for __atomic_is_lock_free and
__c11_atomic_is_lock_free, and implement __atomic_always_lock_free.

Contrary to their documentation, GCC's __atomic_fetch_add family don't
multiply the operand by sizeof(T) when operating on a pointer type.
libstdc++ relies on this quirk. Remove this handling for all but the
__c11_atomic_fetch_add and __c11_atomic_fetch_sub builtins.

Contrary to their documentation, __atomic_test_and_set and __atomic_clear
take a first argument of type 'volatile void *', not 'void *' or 'bool *',
and __atomic_is_lock_free and __atomic_always_lock_free have an argument
of type 'const volatile void *', not 'void *'.

With this change, libstdc++4.7's <atomic> passes libc++'s atomic test suite,
except for a couple of libstdc++ bugs and some cases where libc++'s test
suite tests for properties which implementations have latitude to vary.

llvm-svn: 154640

show more ...

Fix some i1/i8 confusion within _Atomic(bool) in IR generation, both
in general (such an atomic has boolean representation) and
specifically for IR generation of __c11_atomic_init. The latter also
me

Fix some i1/i8 confusion within _Atomic(bool) in IR generation, both
in general (such an atomic has boolean representation) and
specifically for IR generation of __c11_atomic_init. The latter also
means actually using initialization semantics for this initialization,
rather than just creating a store.

On a related note, make sure we actually put in non-atomic-to-atomic
conversions when performing an implicit conversion sequence. IR
generation is far too kind here, but we still want the ASTs to make
sense.

llvm-svn: 154612

show more ...

Implement support for 18 of the GNU-compatible __atomic builtins.

This is not quite sufficient for libstdc++'s <atomic>: we still need
__atomic_test_and_set and __atomic_clear, and may need a more c

Implement support for 18 of the GNU-compatible __atomic builtins.

This is not quite sufficient for libstdc++'s <atomic>: we still need
__atomic_test_and_set and __atomic_clear, and may need a more complete
__atomic_is_lock_free implementation.

We are also missing an implementation of __atomic_always_lock_free,
__atomic_nand_fetch, and __atomic_fetch_nand, but those aren't needed
for libstdc++.

llvm-svn: 154579

show more ...

Make __atomic_init() (soon to be __c11_atomic_init()) work with non-scalar types.

llvm-svn: 154507

Express the number of ULPs in fpaccuracy metadata as a real rather than a
rational number, eg as 2.5 rather than 5, 2. OK'd by Peter Collingbourne.

llvm-svn: 154388

Call out to GCC-compatible runtime functions for atomic ops that we can't use
LLVM intrinsics for.

I have an implementation of these functions, which wants to go in a libgcc_s
equivalent in compiler

Call out to GCC-compatible runtime functions for atomic ops that we can't use
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

show more ...

Revert r153613 as it's causing large compile-time regressions on the nightly testers.

llvm-svn: 153660

When we can't prove that the target of an aggregate copy is
a complete object, the memcpy needs to use the data size of
the structure instead of its sizeof() value. Fixes PR12204.

llvm-svn: 153613

Move the emission of strict enum range metadata behind a flag (the same
flag as GCC uses: -fstrict-enums). There is a *lot* of code making
unwarranted assumptions about the underlying type of enums,

Move the emission of strict enum range metadata behind a flag (the same
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

show more ...

Add back r153360 with a fix for enums that cover all the 32 bit values.
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 produce

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

show more ...

Second part of PR12251. Produce the range metadata in clang for booleans and
c++ enums.

llvm-svn: 153360

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

Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST).

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

Reviewed by Chris La

Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST).

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

Reviewed by Chris Lattner

llvm-svn: 152536

show more ...

Remove BlockDeclRefExpr and introduce a bit on DeclRefExpr to
track whether the referenced declaration comes from an enclosing
local context. I'm amenable to suggestions about the exact meaning
of t

Remove BlockDeclRefExpr and introduce a bit on DeclRefExpr to
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

show more ...

Unify the BlockDeclRefExpr and DeclRefExpr paths so that
we correctly emit loads of BlockDeclRefExprs even when they
don't qualify as ODR-uses. I think I'm adequately convinced
that BlockDeclRefExpr

Unify the BlockDeclRefExpr and DeclRefExpr paths so that
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

show more ...

AST representation for user-defined literals, plus just enough of semantic
analysis to make the AST representation testable. They are represented by a
new UserDefinedLiteral AST node, which is a suga

AST representation for user-defined literals, plus just enough of semantic
analysis to make the AST representation testable. They are represented by a
new UserDefinedLiteral AST node, which is a sugared CallExpr. All semantic
properties, including full CodeGen support, are achieved for free by this
representation.

UserDefinedLiterals can never be dependent, so no custom instantiation
behavior is required. They are mangled as if they were direct calls to the
underlying literal operator. This matches g++'s apparent behavior (but not its
actual mangling, which is broken for literal-operator-ids).

User-defined *string* literals are now fully-operational, but the semantic
analysis is quite hacky and needs more work. No other forms of user-defined
literal are created yet, but the AST support for them is present.

This patch committed after midnight because we had already hit the quota for
new kinds of literal yesterday.

llvm-svn: 152211

show more ...

Generate an AST for the conversion from a lambda closure type to a
block pointer that returns a block literal which captures (by copy)
the lambda closure itself. Some aspects of the block literal are

Generate an AST for the conversion from a lambda closure type to a
block pointer that returns a block literal which captures (by copy)
the lambda closure itself. Some aspects of the block literal are left
unspecified, namely the capture variable (which doesn't actually
exist) and the body (which will be filled in by IRgen because it can't
be written as an AST).

Because we're switching to this model, this patch also eliminates
tracking the copy-initialization expression for the block capture of
the conversion function, since that information is now embedded in the
synthesized block literal. -1 side tables FTW.

llvm-svn: 151131

show more ...

Fix wrong-code bug: __imag on a scalar lvalue should produce a zero rvalue,
rather than an lvalue referring to the scalar.

llvm-svn: 150889