This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.3 release criteria
- From: Matt Austern <austern at apple dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: Christoph Hellwig <hch at infradead dot org>, Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>, tm_gccmail at mail dot kloo dot net, Lars Segerlund <lars dot segerlund at comsys dot se>, gcc at gcc dot gnu dot org, Stuart Hastings <stuart at apple dot com>
- Date: Tue, 25 Feb 2003 15:22:08 -0800
- Subject: Re: GCC 3.3 release criteria
On Tuesday, February 25, 2003, at 03:00 PM, Daniel Jacobowitz wrote:
On Tue, Feb 25, 2003 at 02:33:14PM -0800, Michel LESPINASSE wrote:
On Tue, Feb 25, 2003 at 02:23:48PM -0800, Matt Austern wrote:
How can it be what existing code expects, when it's not what the
existing compiler does? I agree with you that "silently changing
semantics is not a very good idea", which is why we shouldn't
change inline from a hint into a directive except in a special
non-default compilation mode.
The gcc compilers previous to 3.2 used to almost always follow that
hint.
People are just starting to transition to 3.2 and are already
complaining.
In addition, it's the documented behavior - check what our manual says
about inline sometime.
Yes and no. One section, "an inline function is as fast as a macro",
implies that a function that's declared inline will always be
inlined (at least if you're using -O and if the function doesn't use
constructs that are unsuitable for inlining).
Another section, the documented behavior of -finline-limit, makes it
clear that functions that are declared inline do not always get
inlined, that the compiler imposes a size limit.
Another section, "Hints" within "C implementation-defined behavior",
makes it clear that the degree to which functions will be inlined is
implementation defined behavior, and yet another section, "Vague
Linkage", in "Extensions to the C++ Language", promises only that
"Hopefully they can usually be inlined".
The reason for this confusion, of course, is that different sections
of the manual were written by different people and at different
times. It might be a good idea to make things more consistent at
some point.
Since we're talking about 3.3,... I think it would be inappropriate
to make a major change in default inlining behavior so close to the
release. That's why I'm suggesting adding a switch, so that the
people who want 'inline' to be treated as a firm directive can get
the behavior they're looking for.
--Matt