This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: std::pow implementation
Alexandre Oliva <aoliva@redhat.com> writes:
| 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.
If you give inline its original meaning, you won't run into the risk
of the situation you're describing.
[...]
| 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.
Why do you think "inline" is different?
-- Gaby