[cfe-dev] Possible problem with debug metadata generated for empty 'return' statements

Eli Bendersky eliben at gmail.com
Thu Sep 1 09:45:00 PDT 2011


On Thu, Sep 1, 2011 at 18:40, Bob Wilson <bob.wilson at apple.com> wrote:

> Can you file this as a bug report?  http://www.llvm.org/bugs/
>
>
Done: http://www.llvm.org/bugs/show_bug.cgi?id=10829

Eli







> On Sep 1, 2011, at 3:00 AM, Eli Bendersky wrote:
>
> > Hello,
> >
> > Consider this C code:
> >
> >     void func(char c, char* d)
> >     {
> >         *d = c + 1;
> >         return;
> >     }
> >
> > The LLVM IR generated with "clang -g -S -O0 -emit-llvm" is:
> >
> >     define void @func(i8 signext %c, i8* %d) nounwind {
> >     entry:
> >       %c.addr = alloca i8, align 1
> >       %d.addr = alloca i8*, align 4
> >       store i8 %c, i8* %c.addr, align 1
> >       call void @llvm.dbg.declare(metadata !{i8* %c.addr}, metadata !11),
> !dbg !13
> >       store i8* %d, i8** %d.addr, align 4
> >       call void @llvm.dbg.declare(metadata !{i8** %d.addr}, metadata
> !14), !dbg !16
> >       %tmp = load i8* %c.addr, align 1, !dbg !17
> >       %conv = sext i8 %tmp to i32, !dbg !17
> >       %add = add nsw i32 %conv, 1, !dbg !17
> >       %conv1 = trunc i32 %add to i8, !dbg !17
> >       %tmp2 = load i8** %d.addr, align 4, !dbg !17
> >       store i8 %conv1, i8* %tmp2, !dbg !17
> >       ret void, !dbg !19
> >     }
> >
> > Relevant metadata nodes:
> >
> >     !17 = metadata !{i32 3, i32 5, metadata !18, null}
> >     !19 = metadata !{i32 5, i32 1, metadata !18, null}
> >
> > As you can see, the metadata node attached to the 'ret void' instruction
> reports line 5, although the 'return' is on line 4. This is an error, which
> will cause a breakpoint placed on the 'return' not to stop there.
> > Some preliminary investigation in the source code of Clang reveals that
> in all likeness Clang optimizes away the empty "return" at the end of the
> function, using its own return inserted by
> CodeGenFunction::EmitFunctionEpilog
> >
> > Examination of emitted AST shows that the return statement appears there,
> so the optimization is done after that.
> >
> > Eli
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110901/fb1a13f0/attachment.html>


More information about the cfe-dev mailing list