#1108 keyword inline should not cause an error

closed-fixed
Erik Petrich
5
2013-05-25
2006-04-28
No

SDCC may silently ignore the keyword inline but it may
not cause an error.

(A related feature request asking for SDCC implementing
the actual inlining is at:
https://sourceforge.net/tracker/index.php?func=detail&aid=785200&group_id=599&atid=350599
)

-------8<----------
int a;

inline void f(void)
{
a++;
}

Discussion

  • Maarten Brock
    Maarten Brock
    2006-04-28

    Logged In: YES
    user_id=888171

    I would only accept this as valid if the inline function
    is/becomes static. A lot of inline functions are
    implemented in a header file. An extra warning would be
    appropriate.

     
  • Logged In: YES
    user_id=589052

    I agree that it makes much more sense in conjunction with
    static :)

    On the other hand the ANSI C draft
    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
    lists an example without static in §6.7.4.7. So if we
    consider deviation from ANSI C a bug then this is one.
    Giving an extra warning as you proposed would be fine?

     
  • Maarten Brock
    Maarten Brock
    2006-05-02

    Logged In: YES
    user_id=888171

    I read §6.7.4 and wonder whether 6.7.4.8 is incorrect. It
    states cels has external linkage, but I think that should
    be fahr.

    It also seems inline already has a meaning similar to
    static when all declarations use inline, making it
    an "inline definition".

    It looks to me as if it's ok to implement inline as static
    for "inline definitions" and ignore it for inline
    functions with external linkage. If this is as fast as we
    can do at the moment, it's "as fast as possible" (6.7.4.5).

     
  • Erik Petrich
    Erik Petrich
    2006-05-16

    • assigned_to: nobody --> epetrich
     
  • Erik Petrich
    Erik Petrich
    2006-05-16

    Logged In: YES
    user_id=635249

    I'll take care of integrating the "inline" keyword (as well
    as "restrict") into the grammer, but defer an attempt at
    actual inlining until after the next release.

    Maarten, I think you must be looking at an older draft. Both
    the official copy of the standard as well as the draft copy
    that Frieder references state that fahr is an external
    definition and cels is an inline definition.

     
  • Maarten Brock
    Maarten Brock
    2006-05-16

    Logged In: YES
    user_id=888171

    I'm looking in two versions, one being the n1124 draft. I
    see the same line, but the next states "cels has external
    linkage" which I do not understand.

     
  • Erik Petrich
    Erik Petrich
    2006-05-16

    Logged In: YES
    user_id=635249

    Ah I see what you mean now. After a few hours of confusion,
    here is my current understanding:

    From 6.2.2p5 "If the declaration of an identifier for a
    function has no storage-class specifier, its linkage is
    determined exactly as if it were declared with the
    storage-class specifier extern."

    From 6.2.2p4, describing the linkage effects of extern, "If
    no prior declaration is visible, or if the prior declaration
    specified no linkage, then the identifier has external linkage."

    Thus, since cels() has no storage-class specifier (static or
    extern) in its declaration and there was no prior
    declaration of static cels(), it has external linkage.

    Ok, so what about fahr()? Using my two references above, I
    must conclude that it too has external linkage.

    Looking back at the introduction to the example, I realize
    now that both functions were meant to have external linkage
    and that they were trying to show that a function with
    external linkage could still have either an inline or
    external definition.

    The example only provides an inline definition for cels().
    All referenced functions with external linkage require an
    external definition somewhere (see 6.9p5); cells() is in
    this situation. Therefore, an external declaration for
    cels() must exist in some other file.

    So it appears there are three (inline related, non-error)
    cases to handle:

    1) Function is declared as static inline: internal linkage
    and inline definition. We can a) ignore the inline
    definition and handle the function as if it were just
    declared static, b) perform the inlining, or c) both (might
    be needed if the address-of operator is used on the function)

    2) Function is declared as inline only (no static or
    extern): external linkage and inline definition. We can a)
    discard the definition and bind all references to the
    required external definition, or b) perform inlining where
    feasible and bind everything else to the required external
    definition.

    3) Function is declared as extern inline: external linkage
    and external definition. We must generate code for the
    definition. Furthermore, we can a) bind all references to
    this definition, or b) perform inlining where feasible and
    bind everything else to this definition.

    It has also occured to me that the compiler needs to be
    careful to not blindly attempt to inline everything marked
    as inlineable. Otherwise this might take a very long time to
    compile:

    static inline recurse(void) { recurse(); }

     
  • Erik Petrich
    Erik Petrich
    2007-05-10

    • milestone: --> fixed
    • status: open --> closed-fixed
     
  • Erik Petrich
    Erik Petrich
    2007-05-10

    Logged In: YES
    user_id=635249
    Originator: NO

    As of revision 4719, SDCC correctly parses the inline keyword (assuming c99 keywords are enabled).