This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: std::pow implementation
On Jul 29, 2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> Richard Guenther <rguenth@tat.physik.uni-tuebingen.de> writes:
> | At some point the user _will_
> | know better - why do you think we have __attribute__((always_inline)) and
> | __attribute__((noinline))?
> We got __attribute__((always_inline)) because it was decided that the
> compiler knows better than the programmer and the obvious syntax
> "inline" should be a comment. Then people reinvented "inline" with a
> different syntax.
Nope. always_inline was introduced for situations in which, if
inlining does not happen, the program won't run, as it is the case in
early bootstrapping cases in the dynamic loader and in kernels, where
issuing a function call will fail because the code hasn't been
relocated yet. IIRC noinline was introduced for similar (but
opposite) reasons: i.e., where inlining must *not* occur because
otherwise the program would break, e.g., low-level functions that need
the return address of their caller, and not of their caller's caller.
They are not designed to tune inlining, they're designed to impose
requirements on the compiler's behavior. If they're abused for other
purposes, there's unfortunately nothing we can do about it other than
try to educate people about their intended uses.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer