This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Inlining (was: GCC 3.3 release criteria)
- From: Andi Kleen <ak at suse dot de>
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: gcc at gcc dot gnu dot org
- Date: 26 Feb 2003 12:37:52 +0100
- Subject: Re: Inlining (was: GCC 3.3 release criteria)
- References: <F0B5E2D8-48EA-11D7-A0F6-00039390D9E0@apple.com.suse.lists.egcs> <m3wujn90fs.fsf@uniton.integrable-solutions.net.suse.lists.egcs> <20030226044029.A1163@kerberos.ncsl.nist.gov.suse.lists.egcs> <m3isv78gp7.fsf@uniton.integrable-solutions.net.suse.lists.egcs>
Gabriel Dos Reis <gdr at integrable-solutions dot net> writes:
> Olivier Galibert <galibert at pobox dot com> writes:
>
> | On Wed, Feb 26, 2003 at 04:37:43AM +0100, Gabriel Dos Reis wrote:
> | > Does -fobey-inline differ from __attribute__((always_inline))?
> |
> | Yes, with -fobey-inline you only need to change the makefiles, not the
> | source.
>
> Ah, I see what you mean.
>
> This
>
> -Dinline="__attribute__((always_inline)) inline"
>
> (or something to that effect) was suggested earlier. It just needs
> Makefile change.
The naive version of this often breaks because the shell does
funny things to the quotes, especially when the makefile uses a shell
script to call the compiler.
-include somefile.h
and putting it in there works however.
Still this is a semantics change to older compilers, because it implicitely
forces -Werror -Winline
There are some functions that are not inlined for legitimate reasons and
these error out now.
-Andi