[LLVMbugs] [Bug 16649] __attribute__((noreturn)) corrupts instruction pointer on method call

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=16649

reid.kleckner at gmail.com <reid.kleckner at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |reid.kleckner at gmail.com
         Resolution|---                         |INVALID

--- Comment #2 from reid.kleckner at gmail.com <reid.kleckner at gmail.com> ---
The noreturn attribute is part of the method type and is inherited onto the
derived foo method, for better or worse.

TOT clang actually warns you and generates an trap at -O0:

$ clang t.cpp -o t
t.cpp:16:3: warning: control reaches end of non-void function [-Wreturn-type]
  }
  ^
1 warning generated.

$ ./t
foo
Illegal instruction

Clang generates this IR-ish:

  switch i32 %2, label %sw.epilog [
    i32 3, label %sw.bb
    i32 4, label %sw.bb2
  ]

sw.bb:                                            ; preds = %entry
  %3 = load %class.A** %b, align 4
  %4 = bitcast %class.A* %3 to i1 (%class.A*)***
  %vtable = load i1 (%class.A*)*** %4
  %vfn = getelementptr inbounds i1 (%class.A*)** %vtable, i64 0
  %5 = load i1 (%class.A*)** %vfn
  %6 = call x86_thiscallcc zeroext i1 %5(%class.A* %3) #5
  unreachable

; Note the missing call to printf("3\n");

sw.bb2:                                           ; preds = %entry
  %call3 = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([3 x i8]*
@.str, i32 0, i32 0))

Apple clang 4.2 / upstream clang 3.2 appears to simply fall through when the
unreachable is executed.

I think the fact that TOT clang warns on this is enough to declare this Working
As Intended.

-- 
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/20130718/0f3e5adc/attachment.html>