[LLVMbugs] [Bug 14552] New: asm label miscompiled

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Sat Dec 8 22:40:44 PST 2012


             Bug #: 14552
           Summary: asm label miscompiled
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


void other();
extern "C" {
 extern void __foo(int) __asm__("foo");  // #1
 extern __inline __attribute__((__always_inline__)) void foo(int i) {  // #2
   if (i) other(); else __foo(i);

int main(int argc, char**argv) {

Clang implements the asm attribute in IRGen by changing the name of the LLVM IR
function it creates. always_inline is implemented in LLVM by the always
inlininer pass.

So main calls 'foo' and finds #2. That function will get emitted to LLVM IR
with its own name, @foo. It calls __foo which finds #1, that get emitted as a
declaration with the name in the asm label, @foo. Hence, function #2 is emitted
as an infinite loop that calls itself.

The way gcc does this is that it keeps the asm-names around through to the very
late phase of codegen, then applies the name substitution when printing out the
.s file. That allow sthe always_inliner to do its business, moving the call of
__foo into main(), then substituting that for a call to 'foo' when emitting the
.s, and never emitting a body for #2.

If you coerce gcc into emitting the body of #2 (via taking its address), gcc
will also emit a foo that has an infinite loop.

It's important to note that we shouldn't break LTO either. If we happen to have
a function that calls f() asm("g") and we LTO that against an implementation of
g(), we should at least not miscompile it, actually optimizing that seems

One way to fix this is to add "asm label" to llvm::Function and in the LangRef,
etc., and do the substitution very late as gcc does.

Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the llvm-bugs mailing list