Inline semantics.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Inline semantics.

Richard Pennington
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 is
inlined in the file that defines it. If I do function inlining during
bitcode linking instead, everything works OK and the function is inlined
everywhere it is used.

My question is, what should happen in this case? I don't mind deferring
  inlining until the link phase, but I have a feeling that that isn't
correct behavior. Should a diagnostic be issued in this case?

-Rich
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Inline semantics.

Chris Lattner
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  
> is
> inlined in the file that defines it. If I do function inlining during
> bitcode linking instead, everything works OK and the function is  
> inlined
> everywhere it is used.
>
> My question is, what should happen in this case? I don't mind  
> deferring
>  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  
each one.

Please don't cc the oink and llvmdev lists.  The oink list is a closed  
list.

-Chris
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev