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

llvm-svn: 153613

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: 153385

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

llvm-svn: 153380

c++ enums.

llvm-svn: 153360

relied on an artifact of how the inliner and subsequent passes in
clang's -O3 mode happen to treat basic blocks and the labels for the
basic blocks. In my work on the inliner, and changed this fundamental
assumption, and the label that was being checked on the entry basic
block will no longer appear in opt builds. There was no reason to expect
the label to always be present anyways, much to my regret.

I've changed the test to just ensure that we return an immediate
constant. If there are intervening instructions, that's bad, but not
really that relevant to the test.

I'd love it if others have a better way of checking that a function body
contains only a 'ret' instruction that isn't dependent on whether or not
the entry block receives a label...

llvm-svn: 153243

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

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: 152963

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

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

void f () {
  int g (int a, int b=4);
  {
    int g(int a, int b=5);
  }
}

should compile.

llvm-svn: 152621

llvm-svn: 152493

doing a copy. Fixes PR12139.

llvm-svn: 152485

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

llvm-svn: 152470

and lots of tidying up.

llvm-svn: 152392

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

llvm-svn: 152317

user-defined-floating-literal. Support for raw forms of these literals
to follow.

llvm-svn: 152302

llvm-svn: 152277

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

is not usable in a constant expression. ~2.5% speedup on 403.gcc / combine.c.

llvm-svn: 152193

llvm-svn: 152048

In the included testcase, soma thinks that we already have a definition after we
see the out of line decl. Codegen puts it in a deferred list, to be output if
a use is seen. This would break when we saw an explicit template instantiation
definition, since codegen would not be notified.

This patch adds a method to the consumer interface so that soma can notify
codegen that this decl is now required.

llvm-svn: 152024

Fix a bug in the mangler where in 'namespace std { extern "C" {X;} }', X would not be seen to be in ::std::.

Migrate two other places where the same logic is used to use the helper function that already exists.

llvm-svn: 152022

llvm-svn: 151992

scalar emission of DeclRefExprs to const bools: emit scalar bools as i1,
not as i8.

In addition to the extra unit testing, this has successfully bootstrapped.

llvm-svn: 151955

Revert r151879, r151880, "PR12145: Avoid emitting loads of constexpr variables in contexts where there" and "Fix buildbot: make this test less dependent on the value names in the produced IR."

They broke bootstrap.

llvm-svn: 151922

llvm-svn: 151880

is no odr-use of the variable. Go slightly beyond what the standard requires
for variables of reference type.

llvm-svn: 151879

shouldn't be relying on assembly emission.

For the record we should check the metadata output from the front
end and then check in the backend that such a thing emits a pubtypes
entry.

llvm-svn: 151851

correctly.

Still rdar://10900684

llvm-svn: 151838

info.", which broke some -O0 -g tests.

llvm-svn: 151730

This currently doesn't handle capturing the 'this' pointer for any
enclosing class.

Steal the lambda-expressions.cpp testcase and debugify it and try
to use more variables to proof it against random changes.

Part of rdar://10900684

llvm-svn: 151702