<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:codeman.consulting@gmail.com" title="Gordon Keiser <codeman.consulting@gmail.com>"> <span class="fn">Gordon Keiser</span></a>
</span> changed
<a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED - Labels generated, but no code above 'O0'"
href="https://bugs.llvm.org/show_bug.cgi?id=35508">bug 35508</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>INVALID
</td>
<td>---
</td>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>CLOSED
</td>
<td>REOPENED
</td>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>codeman.consulting@gmail.com
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED - Labels generated, but no code above 'O0'"
href="https://bugs.llvm.org/show_bug.cgi?id=35508#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED - Labels generated, but no code above 'O0'"
href="https://bugs.llvm.org/show_bug.cgi?id=35508">bug 35508</a>
from <span class="vcard"><a class="email" href="mailto:codeman.consulting@gmail.com" title="Gordon Keiser <codeman.consulting@gmail.com>"> <span class="fn">Gordon Keiser</span></a>
</span></b>
<pre>In my version of Clang I get the following:
Z:\Code>clang --version
clang version 5.0.0 (<a href="https://github.com/llvm-mirror/clang.git">https://github.com/llvm-mirror/clang.git</a>
adf03c776be767d5d56fdb20c56ec4f6df0b33e6)
(<a href="https://github.com/llvm-mirror/llvm.git">https://github.com/llvm-mirror/llvm.git</a>
7bfd7c00d76359356c3572222f33b03931972c9f)
Z:\Code>clang -S -O1 nocode.cpp -o nocode2.s
Z:\Code>type nocode2.s
.text
.def "?func@@YAXPEAH@Z";
.scl 2;
.type 32;
.endef
.globl "?func@@YAXPEAH@Z"
.p2align 4, 0x90
"?func@@YAXPEAH@Z": # @"\01?func@@YAXPEAH@Z"
# BB#0:
ud2
Which makes sense and seems correct at first glance with the undefined
instruction replacing the incorrect pointer code. However, I get a completely
different result following a run through LLC at O1:
Z:\Code>clang -O0 nocode.cpp -emit-llvm -c
Z:\Code>llc -filetype=asm nocode.bc -O1 -o nocode1.s -x86-asm-syntax=intel
Z:\Code>type nocode1.s
.text
.intel_syntax noprefix
.def "?func@@YAXPEAH@Z";
.scl 2;
.type 32;
.endef
.globl "?func@@YAXPEAH@Z"
.p2align 4, 0x90
"?func@@YAXPEAH@Z": # @"\01?func@@YAXPEAH@Z"
.Lcfi0:
.seh_proc "?func@@YAXPEAH@Z"
# BB#0:
sub rsp, 24
.Lcfi1:
.seh_stackalloc 24
.Lcfi2:
.seh_endprologue
mov qword ptr [rsp + 16], rcx
mov qword ptr [rsp + 8], 0
mov dword ptr [rsp + 4], 0
cmp dword ptr [rsp + 4], 15
jg .LBB0_3
.p2align 4, 0x90
.LBB0_2: # =>This Inner Loop Header: Depth=1
mov rax, qword ptr [rsp + 8]
mov eax, dword ptr [rax]
mov dword ptr [rsp], eax
mov rax, qword ptr [rsp + 16]
lea rcx, [rax + 4]
mov qword ptr [rsp + 16], rcx
mov ecx, dword ptr [rsp]
sub ecx, dword ptr [rax]
mov dword ptr [rsp], ecx
mov rax, qword ptr [rsp + 8]
lea rdx, [rax + 4]
mov qword ptr [rsp + 8], rdx
mov dword ptr [rax], ecx
inc dword ptr [rsp + 4]
cmp dword ptr [rsp + 4], 15
jle .LBB0_2
.LBB0_3:
add rsp, 24
ret
.seh_handlerdata
.text
.Lcfi3:
.seh_endproc
Same at O2 or O3.
In this case *b is generated as a local stack variable at [rsp+8], followed by
j at [rsp+4] and finally c at [rsp]. The value of *z is unknown, but c is an
obvious null ptr deref. For some reason the LLC build doesn't recognize this
as a null ptr derefence and generates the rest of the loop.
Now my question is, shouldn't the assembly output of llc -O1 on bitcode be the
same as clang -O1 on the .cpp file? On windows they don't at least. That
seems like a actual bug to me, in theory we should get nearly identical code
from both methods of doing this. Even at -O3 LLC doesn't reduce to UDF.
My opinion on this particular report is mixed; by reducing to UDF we lose the
ability for a null ptr dereference exception to be thrown, and hence debugging
info for the problem even though it's obvious. I think that's at least worth
looking at; I remember a discussion about it before but if the code is
invalid, why not just error out compiling when the null ptr deref is hit and
diagnose it there rather than create an executable where the problem can no
longer be easily solved?
In addition, clang -O1 -m32 produces the following instead:
Z:\Code>type nocode5.s
.text
.def @feat.00;
.scl 3;
.type 0;
.endef
.globl @feat.00
@feat.00 = 1
.def "?func@@YAXPAH@Z";
.scl 2;
.type 32;
.endef
.globl "?func@@YAXPAH@Z"
.p2align 4, 0x90
"?func@@YAXPAH@Z": # @"\01?func@@YAXPAH@Z"
# BB#0:
nop # avoids zero-length function
.def _main;
.scl 2;
.type 32;
.endef
.globl _main
.p2align 4, 0x90
...
Now that situation is just completely incorrect, as the NOP is executed and the
debugger breaks in main with an invalid dereference of argv** because the
function it was calling just falls back through to it. Even the UDF is better
than that and I think this is an actual bug if it's still happening in ToT. My
windows build isn't up to date at the moment but I'm reopening because of that
last example.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>