[LLVMbugs] [Bug 8859] New: extern __inline__ causes multiple def'n errors

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Sat Dec 25 21:33:38 PST 2010


           Summary: extern __inline__ causes multiple def'n errors
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu

Consider the two files:

== a ==
  extern __inline__ void foo() { return; }
  void test_a() { foo(); return; }
== b ==
  extern __inline__ void foo() { return; }
  void test_b() { foo(); return; }

compiled *without* optimization, so that inlining doesn't happen. For
reference, the GCC documentation on it is here:
http://gcc.gnu.org/onlinedocs/gcc/Inline.html and it pretty much states that
extern inline can't generate a definition.

Here's the real-world manifestation of the problem:

  $ gcc a.c -c -o a.o
  $ gcc b.c -c -o b.o
  $ ld -r a.o b.o
  $ clang a.c -c -o a.o
  $ clang b.c -c -o b.o
  $ ld -r a.o b.o
  ld: error: multiple definition of `foo'
  ld: a.o: previous definition here

What did GCC actually do with this declaration? The assembly makes no
declaration of foo at all, it just emits a "call foo" instruction in test_A.
Clang emitted:

          .file   "a.c"
          .globl  foo
          .align 16, 0x90
          .type foo, at function

Which is clearly more than it needed to. But what about C++? Things are a
little bit different there: GCC *does* emit the function. Here's the relevant
portion of the assembly:

  $ g++ a.cc -S -o -
          .file    "a.cc"
          .section        .text._Z3foov,"axG", at progbits,_Z3foov,comdat
          .weak    _Z3foov
          .type    _Z3foov, @function

Clang just emits a normal linkonce_odr function with:
          .section        .gnu.linkonce.t._Z3foov,"ax", at progbits
          .weak   _Z3foov
          .align  16, 0x90
          .type   _Z3foov, at function

In either case, Clang is getting this wrong and it's causing multiple
definition errors where the GCC extension says they shouldn't be happening. I'm
not sure whether the problem is in the linkage type selected by clang when
lowering to llvm or whether the lowering of linkonce functions to elf .section
rules is wrong.

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