This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: inline functions and local labels


    But it is valid to do so in GNU C, and it has been so for years, also
    the documentation does not state otherwise.  The code in question in
    the Linux kernel is:

    This is a useful technique that the GNU extensions have allowed for
    quite some time now.

    One could argue that the user might be baffled if he did not expect
    this behavior.  So I wouldn't mind if, for example, -finline-functions
    would not choose to inline the above if the __inline__ tag were not
    present.

    But when a user uses the constructs above, and specifies "I wish this
    to be inlined" we should trust the programmer that he knows what he is
    doing.

No, we shouldn't!  The programmer isn't supposed to know what the compiler
is and is not capable of doing properly, especially since that changes.

Inlining tells the compiler "for efficiency reasons, I'd like you to
do your best to inline this function", not "even if you do it wrong, I'd 
like you to inline it".

       But when there are just the addresses of labels, we produce confusing
       results.

    Confusing to who?

To at least the test case I saw.  The point is that the semantics of a function
should not change if it's inlined or not.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]