[llvm-bugs] [Bug 35508] Labels generated, but no code above 'O0'
via llvm-bugs
llvm-bugs at lists.llvm.org
Sun Dec 3 17:58:54 PST 2017
https://bugs.llvm.org/show_bug.cgi?id=35508
Gordon Keiser <codeman.consulting at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |---
Status|CLOSED |REOPENED
CC| |codeman.consulting at gmail.co
| |m
--- Comment #3 from Gordon Keiser <codeman.consulting at gmail.com> ---
In my version of Clang I get the following:
Z:\Code>clang --version
clang version 5.0.0 (https://github.com/llvm-mirror/clang.git
adf03c776be767d5d56fdb20c56ec4f6df0b33e6)
(https://github.com/llvm-mirror/llvm.git
7bfd7c00d76359356c3572222f33b03931972c9f)
Z:\Code>clang -S -O1 nocode.cpp -o nocode2.s
Z:\Code>type nocode2.s
.text
.def "?func@@YAXPEAH at Z";
.scl 2;
.type 32;
.endef
.globl "?func@@YAXPEAH at Z"
.p2align 4, 0x90
"?func@@YAXPEAH at Z": # @"\01?func@@YAXPEAH at 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 at Z";
.scl 2;
.type 32;
.endef
.globl "?func@@YAXPEAH at Z"
.p2align 4, 0x90
"?func@@YAXPEAH at Z": # @"\01?func@@YAXPEAH at Z"
.Lcfi0:
.seh_proc "?func@@YAXPEAH at 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 at Z";
.scl 2;
.type 32;
.endef
.globl "?func@@YAXPAH at Z"
.p2align 4, 0x90
"?func@@YAXPAH at Z": # @"\01?func@@YAXPAH at 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.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171204/ffd19b49/attachment.html>
More information about the llvm-bugs
mailing list