implement it explicitly or assert that it doesn't make sense for a scalar.
This caught a couple interesting issues: one, CK_BaseToDerivedMemberPointer
casts were getting silently miscompiled, and two, Sema was constructing some
strange implicit casts of type CK_UserDefinedConversion.

The change in SemaExprCXX makes sure the cast kinds are getting set correctly.

llvm-svn: 89987

llvm-svn: 89986

llvm-svn: 89985

we check whether the vtable needs to be generated.

llvm-svn: 89984

llvm-svn: 89983

llvm-svn: 89982

This allows us to compile the example from PR5313 into:

LBB1_2:                                                     ## %bb
	incl	%ecx
	movb	%al, (%rsi)
	movslq	%ecx, %rax
	movb	(%rdi,%rax), %al
	testb	%al, %al
	jne	LBB1_2

instead of:

LBB1_2:                                                     ## %bb
	movslq	%eax, %rcx
	incl	%eax
	movb	(%rdi,%rcx), %cl
	movb	%cl, (%rsi)
	movslq	%eax, %rcx
	cmpb	$0, (%rdi,%rcx)
	jne	LBB1_2

llvm-svn: 89981

SimplifyGEPInst method in InstructionSimplify.h.  No functionality change.

llvm-svn: 89980

come.

llvm-svn: 89979

the example in GCC PR16799 to:

LBB1_2:                                                     ## %bb1
	movl	%eax, %eax
	subq	%rax, %rdi
	movq	%rdi, (%rcx)
	movl	(%rdi), %eax
	testl	%eax, %eax
	je	LBB1_2

instead of:

LBB1_2:                                                     ## %bb1
	movl	(%rdi), %ecx
	subq	%rcx, %rdi
	movq	%rdi, (%rax)
	cmpl	$0, (%rdi)
	je	LBB1_2

llvm-svn: 89978

llvm-svn: 89977

llvm-svn: 89976

llvm-svn: 89975

llvm-svn: 89974

remove in LLVM 3.0

llvm-svn: 89973

llvm-svn: 89972

generates store to undef and some generates store to null as the idiom
for undefined behavior.  Since simplifycfg zaps both, don't remove the
undefined behavior in instcombine.

llvm-svn: 89971

by Alastair Lynn.

llvm-svn: 89970

llvm-svn: 89968

When adding an implicit destructor, make sure to mark it as virtual if it overrides existing destructors.

llvm-svn: 89967

llvm-svn: 89966

llvm-svn: 89965

Make the pure virtual methods map a set instead.

llvm-svn: 89961

first expression as P+4+4*i which we considered to possibly alias
P+4*j.  Now we correctly analyze the former one as P+1+4*i.

@test10 is a sanity test that verfies that we know that P+4+4*i != P+4*i.

llvm-svn: 89960

previously already handled it at -m32 because there were no i32->i64 
extensions for addressing.

llvm-svn: 89959

llvm-svn: 89958

llvm-svn: 89957

llvm-svn: 89956

llvm-svn: 89955

to exercise this though.

llvm-svn: 89954

only missing the one form (in this testcase).  Dan, do you
consider this example to be important?

llvm-svn: 89953

allows us to compile the example in readme.txt into:

LBB1_1:                                                     ## %bb
	movl	4(%rdx,%rax), %ecx
	movl	%ecx, %esi
	imull	(%rdx,%rax), %esi
	imull	%esi, %ecx
	movl	%esi, 8(%rdx,%rax)
	imull	%ecx, %esi
	movl	%ecx, 12(%rdx,%rax)
	movl	%esi, 16(%rdx,%rax)
	imull	%ecx, %esi
	movl	%esi, 20(%rdx,%rax)
	addq	$16, %rax
	cmpq	$4000, %rax
	jne	LBB1_1

instead of:

LBB1_1: 
	movl	(%rdx,%rax), %ecx
	imull	4(%rdx,%rax), %ecx
	movl	%ecx, 8(%rdx,%rax)
	imull	4(%rdx,%rax), %ecx
	movl	%ecx, 12(%rdx,%rax)
	imull	8(%rdx,%rax), %ecx
	movl	%ecx, 16(%rdx,%rax)
	imull	12(%rdx,%rax), %ecx
	movl	%ecx, 20(%rdx,%rax)
	addq	$16, %rax
	cmpq	$4000, %rax
	jne	LBB1_1

GCC (4.2) doesn't seem to be able to eliminate the loads in this 
testcase either, it generates:

L2:
	movl	(%rdx), %eax
	imull	4(%rdx), %eax
	movl	%eax, 8(%rdx)
	imull	4(%rdx), %eax
	movl	%eax, 12(%rdx)
	imull	8(%rdx), %eax
	movl	%eax, 16(%rdx)
	imull	12(%rdx), %eax
	movl	%eax, 20(%rdx)
	addl	$4, %ecx
	addq	$16, %rdx
	cmpl	$1002, %ecx
	jne	L2

llvm-svn: 89952

llvm-svn: 89951

llvm-svn: 89950

llvm-svn: 89949

this brings the error on
  clang -c foo.h -o -
closer to
  clang -c foo.h -o /dev/null

llvm-svn: 89948

llvm-svn: 89947

llvm-svn: 89946

llvm-svn: 89945

llvm-svn: 89944