This is the mail archive of the gcc@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]
Other format:	[Raw text]

Re: GCC 3.3 release criteria

From: Dale Johannesen <dalej at apple dot com>
To: Matt Austern <austern at apple dot com>
Cc: Dale Johannesen <dalej at apple dot com>, Daniel Jacobowitz <drow at mvista dot com>, 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:42:59 -0800
Subject: Re: GCC 3.3 release criteria

On Tuesday, February 25, 2003, at 03:22 PM, Matt Austern wrote:

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).

Yes, you wouldn't know there are limitations from that section; it needs a rewrite. It also says forward-referenced calls are not inlined, which isn't true any longer.

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.

There are also several other currently undocumented flags that affect the choice of what gets inlined, and -finline-limit does not work as documented. Could somebody please approve the patch for this bug? PR 8387.

References:
- Re: GCC 3.3 release criteria
  - From: Matt Austern

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