[LLVMbugs] [Bug 3355] New: llvm handles inline functions in C99 poorly

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.org/bugs/show_bug.cgi?id=3355

           Summary: llvm handles inline functions in C99 poorly
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Support Libraries
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dalej at apple.com
                CC: llvmbugs at cs.uiuc.edu


A refresher:  the semantics of function definitions declared "inline" in C99
are that the body may be substituted into callers within that compilation unit,
but this should not create an external definition for use in other compilation
units.  There must be a (non-inline) definition in some other compilation unit,
and there is no requirement that it be functionally equivalent to the one in
this file; it's "unspecified behavior" if that happens (not "undefined").

Note that gcc-89 provides equivalent functionality using "extern inline" in a
way that's incompatible with C99, and that comments within the gcc sources use
"extern inline" for these semantics.  Also note C++ semantics for inline are
completely different, but you knew that.

Moving the inlining phase from gcc to llvm sort of broke this.  Currently we
(i.e. cgraph in llvm-gcc) treats these functions by not passing them into
llvm's inliner, which is correct but not very useful.  If we do pass them in we
should have a way to tell llvm not to generate a definition for them, and I
don't think there is one.  (Although pretending they are static may work OK in
practice; if something doesn't get inlined that will wind up invoking a
different leg of unspecified behavior, which is conformant but may be
surprising.  It's a hack, though.)

For always-inline C99 inline functions, llvm needs to see the bodies for
correctness.  I've fixed that case using the "static" hack (a static definition
may be emitted, but that's harmless since nothing can reference it).  But even
here I'd prefer to have a way to tell llvm not to emit the body, for QOI if
nothing else.

So I'm suggesting an IR extension here.


-- 
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.