Possible bug in latest version of clang on Mac OS X

[Doug Simon]

Since I have automatic updating enabled on my Mac, I was recently updated to the latest version of Xcode (5.1). I have just done my first recompile of HotSpot since this update and am seeing that clang appears to have a rather serious bug. In both disassembled functions below, the third parameter (%rdx) is a jobject that should be resolved via JNIHandles::resolve and then dereferenced *after* adding the fourth parameter (%rcx) to it. clang is inlining the call to JNIHandles::resolve but omitting the null check on the jobject value.

If this is really a bug, I’m sure reports about it will start showing up soon. In the meantime, don’t update Xcode.

-Doug


_Unsafe_GetLong:
0000000000357e59	pushq	%rbp
0000000000357e5a	movq	%rsp, %rbp
0000000000357e5d	pushq	%r15
0000000000357e5f	pushq	%r14
0000000000357e61	pushq	%r12
0000000000357e63	pushq	%rbx
0000000000357e64	subq	$0x10, %rsp
0000000000357e68	movq	%rcx, %r14
0000000000357e6b	movq	%rdx, %r15
0000000000357e6e	movq	%rdi, %rbx
0000000000357e71	movl	0x90(%rbx), %eax
0000000000357e77	addq	$-0x1f0, %rbx
0000000000357e7e	cmpl	$0xdeab, %eax
0000000000357e83	je	0x357e9c
0000000000357e85	movl	0x280(%rbx), %eax
0000000000357e8b	cmpl	$0xdeac, %eax
0000000000357e90	je	0x357e9c
0000000000357e92	movq	%rbx, %rdi
0000000000357e95	callq	__ZN10JavaThread18block_if_vm_exitedEv
0000000000357e9a	xorl	%ebx, %ebx
0000000000357e9c	leaq	-0x28(%rbp), %r12
0000000000357ea0	movq	%r12, %rdi
0000000000357ea3	movq	%rbx, %rsi
0000000000357ea6	callq	__ZN20ThreadInVMfromNativeC1EP10JavaThread
0000000000357eab	movq	%rbx, -0x30(%rbp)
0000000000357eaf	movq	(%r15), %rax
0000000000357eb2	movq	(%rax,%r14), %rbx
0000000000357eb6	leaq	-0x30(%rbp), %rdi
0000000000357eba	callq	__ZN17HandleMarkCleanerD1Ev
0000000000357ebf	movq	%r12, %rdi
0000000000357ec2	callq	__ZN20ThreadInVMfromNativeD1Ev
0000000000357ec7	movq	%rbx, %rax
0000000000357eca	addq	$0x10, %rsp
0000000000357ece	popq	%rbx
0000000000357ecf	popq	%r12
0000000000357ed1	popq	%r14
0000000000357ed3	popq	%r15
0000000000357ed5	popq	%rbp
0000000000357ed6	ret

__Z33c2v_readUnsafeUncompressedPointerP7JNIEnv_P8_jobjectS2_l:
000000000016e261	pushq	%rbp
000000000016e262	movq	%rsp, %rbp
000000000016e265	pushq	%r15
000000000016e267	pushq	%r14
000000000016e269	pushq	%r12
000000000016e26b	pushq	%rbx
000000000016e26c	subq	$0x10, %rsp
000000000016e270	movq	%rcx, %r14
000000000016e273	movq	%rdx, %r15
000000000016e276	leaq	_TraceGraal(%rip), %rax
000000000016e27d	cmpq	$0x3, (%rax)
000000000016e281	jl	0x16e2ac
000000000016e283	leaq	_tty(%rip), %rbx
000000000016e28a	movq	(%rbx), %rdi
000000000016e28d	leaq	0x23de25(%rip), %rsi ## literal pool for: "      TraceGraal-3: "
000000000016e294	xorl	%eax, %eax
000000000016e296	callq	__ZN12outputStream5printEPKcz
000000000016e29b	movq	(%rbx), %rdi
000000000016e29e	leaq	0x23ef0f(%rip), %rsi ## literal pool for: "CompilerToVM::readUnsafeUncompressedPointer"
000000000016e2a5	xorl	%eax, %eax
000000000016e2a7	callq	__ZN12outputStream8print_crEPKcz
000000000016e2ac	leaq	__ZN18ThreadLocalStorage13_thread_indexE(%rip), %rax
000000000016e2b3	movslq	(%rax), %rdi
000000000016e2b6	callq	0x38a758 ## symbol stub for: _pthread_getspecific
000000000016e2bb	movq	%rax, %rbx
000000000016e2be	leaq	-0x28(%rbp), %r12
000000000016e2c2	movq	%r12, %rdi
000000000016e2c5	movq	%rbx, %rsi
000000000016e2c8	callq	__ZN20ThreadInVMfromNativeC1EP10JavaThread
000000000016e2cd	movq	%rbx, -0x30(%rbp)
000000000016e2d1	movq	(%r15), %rax
000000000016e2d4	movq	(%rax,%r14), %rdi
000000000016e2d8	callq	__ZN10JNIHandles10make_localEP7oopDesc
000000000016e2dd	movq	%rax, %rbx
000000000016e2e0	leaq	-0x30(%rbp), %rdi
000000000016e2e4	callq	__ZN17HandleMarkCleanerD1Ev
000000000016e2e9	movq	%r12, %rdi
000000000016e2ec	callq	__ZN20ThreadInVMfromNativeD1Ev
000000000016e2f1	movq	%rbx, %rax
000000000016e2f4	addq	$0x10, %rsp
000000000016e2f8	popq	%rbx
000000000016e2f9	popq	%r12
000000000016e2fb	popq	%r14
000000000016e2fd	popq	%r15
000000000016e2ff	popq	%rbp
000000000016e300	ret