[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


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

Z:\Code>clang -S -O1 nocode.cpp -o nocode2.s
Z:\Code>type nocode2.s
        .def     "?func@@YAXPEAH at Z";
        .scl    2;
        .type   32;
        .globl  "?func@@YAXPEAH at Z"
        .p2align        4, 0x90
"?func@@YAXPEAH at Z":                     # @"\01?func@@YAXPEAH at Z"
# BB#0:

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
        .intel_syntax noprefix
        .def     "?func@@YAXPEAH at Z";
        .scl    2;
        .type   32;
        .globl  "?func@@YAXPEAH at Z"
        .p2align        4, 0x90
"?func@@YAXPEAH at Z":                     # @"\01?func@@YAXPEAH at Z"
.seh_proc "?func@@YAXPEAH at Z"
# BB#0:
        sub     rsp, 24
        .seh_stackalloc 24
        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
        add     rsp, 24

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
        .def     @feat.00;
        .scl    3;
        .type   0;
        .globl  @feat.00
@feat.00 = 1
        .def     "?func@@YAXPAH at Z";
        .scl    2;
        .type   32;
        .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;
        .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