Hi,
This test case:
inline void f(void) {}
when compiled with llvm-gcc, produces this output:
define void @f() nounwind {
but when compiled with clang, this output:
define weak void @f() {
Should clang mirror llvm-gcc and not use 'weak' linkage for inline functions ?
-Argiris
The correct comparison is with llvm-gcc -std=c99. clang is in fact
wrong here, but it's a bit more complicated.
-Eli
Eli Friedman wrote:
I'm not sure what you mean. Are you not on an ELF system? If not, the llvm backend for your target has a bug.
-Chris
Chris Lattner wrote:
The correct comparison is with llvm-gcc -std=c99. clang is in fact
wrong here, but it's a bit more complicated.Can we change it to 'linkonce' until the correct semantics are in place ?
The issue with 'weak' is that the inliner leaves it untouched and this
section is produced in the assembly output:.section .llvm.linkonce.t._f,"ax",@progbits
which is ELF specific, is this correct ?
I'm not sure what you mean. Are you not on an ELF system? If not, the llvm backend for your target has a bug.
LLVM produces that assembly output on windows too, and I assumed that it's some ELF specific linkage.
I should attribute that to a bug of the llvm backend, right ? Thank you for your response.
-Argiris
Yep sounds like a bug in the windows/x86 backend. Maybe Anton has an idea? Anton, it is emitting the line above with 'weak' linkage symbols.
-Chris
Chris Lattner wrote:
Yep sounds like a bug in the windows/x86 backend. Maybe Anton has an idea? Anton, it is emitting the line above with 'weak' linkage symbols.
I verified that it's the same with 'linkonce'.
This testcase:
define linkonce void @f() {
entry:
ret void
}
produces this section line:
.section .llvm.linkonce.t._f,"ax",@progbits
-Argiris
Hi, Argiris
I verified that it's the same with 'linkonce'.
This testcase:define linkonce void @f() {
entry:
ret void
}produces this section line:
.section .llvm.linkonce.t._f,"ax",@progbits
Are you sure?
I'm having:
$ ./llc weak-test.bc -mtriple=i686-mingw32
.section .text$linkonce._f,"ax"
.align 16
.globl _f
.linkonce discard
.def _f; .scl 2; .type 32; .endef
_f:
Lllvm$workaround$fake$stub$_f:
Llabel1:
ret
this is correct code. weak stuff worked on windows for ages.
Are you sure?
I'm having:
$ ./llc weak-test.bc -mtriple=i686-mingw32
Argiris, is clang putting the right target triple in the module?
-Chris
Chris Lattner wrote:
Are you sure?
I'm having:
$ ./llc weak-test.bc -mtriple=i686-mingw32Argiris, is clang putting the right target triple in the module?
Ah, the MSVC compiled clang puts "i686-pc-win32", that seems to be the problem..
-Argiris
Ah, the MSVC compiled clang puts "i686-pc-win32", that seems to be the
problem..
Well, currently 'windows' subtarget (not mingw) is used only for JITing.
There are no weak symbols there at all, thus backend behaviour is
undefined there 