[LLVMdev] Inline semantics.
sabre at nondot.org
Wed Jan 2 22:54:09 PST 2008
On Jan 2, 2008, at 2:23 AM, Richard Pennington wrote:
> Ellsif compiles and runs bzip2. During testing I noticed that if I set
> the optimization level to O2 or greater, I'd get an unresolved
> symbol at
> link time.
> It turns out that a function is declared in a header file and is
> used by
> two separate source files. In one of the source files, the function is
> defined with __inline__.
> If I do function inlining during compilation (i.e. bitcode creation) I
> get the unresolved symbol because the function is discarded after it
> inlined in the file that defines it. If I do function inlining during
> bitcode linking instead, everything works OK and the function is
> everywhere it is used.
> My question is, what should happen in this case? I don't mind
> inlining until the link phase, but I have a feeling that that isn't
> correct behavior. Should a diagnostic be issued in this case?
The semantics of __inline__ are tricky and vary between C89, C99 and C+
+. You should look at the relevant standards to find the meaning of
Please don't cc the oink and llvmdev lists. The oink list is a closed
More information about the llvm-dev