Re: GCC 3.3 release criteria

Re: GCC 3.3 release criteria

[Andi Kleen]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

> <tr><td><a href="http://www.kernel.org">Linux kernel</a></td>

gcc 3.3 doesn't compile the linux kernels (2.4 and 2.5) very well
currently because the inlining algorithm is too broken. The Linux
kernel often assumes that functions marked "inline" get inlined and
when they aren't it results in linking errors. In a few rare cases
you also get silent miscompilation (this happened in the x86-64 port,
now fixed)

Only good workaround currently is -Dinline="__attribute__((always_inline))",
just using -finline-limit=hugenumber doesn't help.
 
Better would be likely to fix the inlining heuristics to honor the inline
keyword better.

-Andi

Re: GCC 3.3 release criteria

[Jakub Jelinek]

On Mon, Feb 24, 2003 at 09:28:51PM +0100, Andi Kleen wrote:
> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
> 
> > <tr><td><a href="http://www.kernel.org">Linux kernel</a></td>
> 
> gcc 3.3 doesn't compile the linux kernels (2.4 and 2.5) very well
> currently because the inlining algorithm is too broken. The Linux
> kernel often assumes that functions marked "inline" get inlined and
> when they aren't it results in linking errors. In a few rare cases
> you also get silent miscompilation (this happened in the x86-64 port,
> now fixed)
> 
> Only good workaround currently is -Dinline="__attribute__((always_inline))",
> just using -finline-limit=hugenumber doesn't help.
>  
> Better would be likely to fix the inlining heuristics to honor the inline
> keyword better.

Especially nested inline functions.

	Jakub

Re: GCC 3.3 release criteria

[Daniel Jacobowitz]

On Mon, Feb 24, 2003 at 09:28:51PM +0100, Andi Kleen wrote:
> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
> 
> > <tr><td><a href="http://www.kernel.org">Linux kernel</a></td>
> 
> gcc 3.3 doesn't compile the linux kernels (2.4 and 2.5) very well
> currently because the inlining algorithm is too broken. The Linux
> kernel often assumes that functions marked "inline" get inlined and
> when they aren't it results in linking errors. In a few rare cases
> you also get silent miscompilation (this happened in the x86-64 port,
> now fixed)
> 
> Only good workaround currently is -Dinline="__attribute__((always_inline))",
> just using -finline-limit=hugenumber doesn't help.
>  
> Better would be likely to fix the inlining heuristics to honor the inline
> keyword better.

I know this has been explained before, but maybe someone could do it
again until it sticks...

For functions marked with the "inline" keyword, as opposed to C++
inline class methods, can anyone give me a reason why we don't treat
the inline keyword as an always_inline attribute?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GCC 3.3 release criteria

[Franz Sirl]

On Monday 24 February 2003 21:37, Daniel Jacobowitz wrote:
> On Mon, Feb 24, 2003 at 09:28:51PM +0100, Andi Kleen wrote:
> > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
> > > <tr><td><a href="http://www.kernel.org">Linux kernel</a></td>
> >
> > gcc 3.3 doesn't compile the linux kernels (2.4 and 2.5) very well
> > currently because the inlining algorithm is too broken. The Linux
> > kernel often assumes that functions marked "inline" get inlined and
> > when they aren't it results in linking errors. In a few rare cases
> > you also get silent miscompilation (this happened in the x86-64 port,
> > now fixed)
> >
> > Only good workaround currently is
> > -Dinline="__attribute__((always_inline))", just using
> > -finline-limit=hugenumber doesn't help.
> >
> > Better would be likely to fix the inlining heuristics to honor the inline
> > keyword better.
>
> I know this has been explained before, but maybe someone could do it
> again until it sticks...
>
> For functions marked with the "inline" keyword, as opposed to C++
> inline class methods, can anyone give me a reason why we don't treat
> the inline keyword as an always_inline attribute?

I wholeheartedly second that. If I write "inline" in C I expect that to happen 
as soon as the optimizer is turned on. If there is room for even more 
inlining after that, fine.
So, for C "inline" should be mapped to "always_inline".

Franz.

Re: GCC 3.3 release criteria

[Kaveh R. Ghazi]

 > From: Andi Kleen <ak@suse.de>
 > 
 > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
 > 
 > > <tr><td><a href="http://www.kernel.org">Linux kernel</a></td>
 > 
 > gcc 3.3 doesn't compile the linux kernels (2.4 and 2.5) very well
 > currently because the inlining algorithm is too broken. The Linux
 > kernel often assumes that functions marked "inline" get inlined and
 > when they aren't it results in linking errors. In a few rare cases
 > you also get silent miscompilation (this happened in the x86-64 port,
 > now fixed)
 > 
 > Only good workaround currently is -Dinline="__attribute__((always_inline))",
 > just using -finline-limit=hugenumber doesn't help.
 >  
 > Better would be likely to fix the inlining heuristics to honor the inline
 > keyword better.
 > -Andi

Thanks for the info, do we have any high priority PRs filed for this
problem specifically mentioning the inability to compile the kernel?

In the past we've insisted on being able to compile linux, for obvious
reasons beyond simple compiler correctness. :-)

IMO we should continue to meet that criteria, one way or another.

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: GCC 3.3 release criteria

[Andi Kleen]

> Thanks for the info, do we have any high priority PRs filed for this
> problem specifically mentioning the inability to compile the kernel?

I'm not aware of any PRs got filed yet but I can file one or two
with test cases. Will do that tomorrow if nobody beats me 
(can be easily gotten by compiling a 2.4 or 2.5 kernel and watching
the linker errors)

-Andi

Inlining (was: GCC 3.3 release criteria)

[Matt Austern]

On Monday, February 24, 2003, at 12:28 PM, Andi Kleen wrote:

> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
>
>> <tr><td><a href="http://www.kernel.org">Linux kernel</a></td>
>
> gcc 3.3 doesn't compile the linux kernels (2.4 and 2.5) very well
> currently because the inlining algorithm is too broken. The Linux
> kernel often assumes that functions marked "inline" get inlined and
> when they aren't it results in linking errors. In a few rare cases
> you also get silent miscompilation (this happened in the x86-64 port,
> now fixed)

As it happens, Apple may be able to contribute a patch that does what
you're looking for.  We've got a local patch that adds a new command
line switch, -fobey-inline.   The switch does exactly what you think: 
the
compiler will inline every function that's marked 'inline' whenever it's
possible.  (There are still cases where it's not possible, of course, 
e.g.
if you mark a recursive function inline.)

We definitely don't want -fobey-inline to be the default: usually it's
better for the compiler to treat the inline keyword as a hint, and to
use its own heuristics to decide when to accept the hint.  But there are
cases, as you've found, when a flag like this is useful.

If Apple contributed the -fobey-inline patch, would people here be
interested in it?

			--Matt

Re: Inlining (was: GCC 3.3 release criteria)

[Tolga Dalman]

On Mon, 24 Feb 2003 16:32:17 -0800 Matt Austern <austern@apple.com> wrote:

> On Monday, February 24, 2003, at 12:28 PM, Andi Kleen wrote:
> 
> > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
> >
> >> <tr><td><a href="http://www.kernel.org">Linux kernel</a></td>
> >
> > gcc 3.3 doesn't compile the linux kernels (2.4 and 2.5) very well
> > currently because the inlining algorithm is too broken. The Linux
> > kernel often assumes that functions marked "inline" get inlined and
> > when they aren't it results in linking errors. In a few rare cases
> > you also get silent miscompilation (this happened in the x86-64 port,
> > now fixed)
> 
> As it happens, Apple may be able to contribute a patch that does what
> you're looking for.  We've got a local patch that adds a new command
> line switch, -fobey-inline.   The switch does exactly what you think: 
> the
> compiler will inline every function that's marked 'inline' whenever it's
> possible.  (There are still cases where it's not possible, of course, 
> e.g.
> if you mark a recursive function inline.)
> 
> We definitely don't want -fobey-inline to be the default: usually it's
> better for the compiler to treat the inline keyword as a hint, and to
> use its own heuristics to decide when to accept the hint.  But there are
> cases, as you've found, when a flag like this is useful.
> 

this confuses me a bit. i always thought, that the "inline" keyword would
in any case force inlining, except for the -fno-inline flag activated. 
IMHO, the compiler should always obey user inlining, because the compiler 
should trust the programmer when he uses an optional feature (such as inline).
for me, the question evolves: what does happen in -Os optimization? i suppose, 
there isn't done any inline at all, not even explicitely "inline" marked
functions, no?

brg,
Tolga Dalman.

Re: Inlining (was: GCC 3.3 release criteria)

[Steven Bosscher]

Op di 25-02-2003, om 01:32 schreef Matt Austern:
> As it happens, Apple may be able to contribute a patch that does what
> you're looking for.  We've got a local patch that adds a new command
> line switch, -fobey-inline.   The switch does exactly what you think: 
> the
> compiler will inline every function that's marked 'inline' whenever it's
> possible.  (There are still cases where it's not possible, of course, 
> e.g.
> if you mark a recursive function inline.)
> 
> We definitely don't want -fobey-inline to be the default: usually it's
> better for the compiler to treat the inline keyword as a hint, and to
> use its own heuristics to decide when to accept the hint.  But there are
> cases, as you've found, when a flag like this is useful.

The compiler may be able to make better inlining decisionsm, but it
should IMHO never overrule the user.  So if the user says "inline this"
then the compiler should try really hard to do so, even if it thinks the
resulting code is worse than without inlining.

How about making "obey-inline" the default, with a flag to enable a
warning that would make the compiler complain if it thinks the function
shouldn't be inlined?

> If Apple contributed the -fobey-inline patch, would people here be
> interested in it?

Yes.

Greetz
Steven

Re: Inlining (was: GCC 3.3 release criteria)

[Andi Kleen]

On Mon, Feb 24, 2003 at 04:32:17PM -0800, Matt Austern wrote:
> On Monday, February 24, 2003, at 12:28 PM, Andi Kleen wrote:
> 
> >"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
> >
> >><tr><td><a href="http://www.kernel.org">Linux kernel</a></td>
> >
> >gcc 3.3 doesn't compile the linux kernels (2.4 and 2.5) very well
> >currently because the inlining algorithm is too broken. The Linux
> >kernel often assumes that functions marked "inline" get inlined and
> >when they aren't it results in linking errors. In a few rare cases
> >you also get silent miscompilation (this happened in the x86-64 port,
> >now fixed)
> 
> As it happens, Apple may be able to contribute a patch that does what
> you're looking for.  We've got a local patch that adds a new command
> line switch, -fobey-inline.   The switch does exactly what you think: 
> the
> compiler will inline every function that's marked 'inline' whenever it's
> possible.  (There are still cases where it's not possible, of course, 
> e.g.
> if you mark a recursive function inline.)

Yes, that is why I don't like the -Dinline="__attribute__((always_inline)) inline"
way too much - there are a few valid reasons why inline functions marked
inline didn't get inlined and this define changes behaviour for them
by essentially forcing -Winline -Werror

> If Apple contributed the -fobey-inline patch, would people here be
> interested in it?

I would still prefer if inline was much stronger for C programs by default
(I realize that the situation is different for C++ where inline is used
much more frequently and in a different way), but failing that
-fobey-inline would be useful too. The problems seem to root in trying
to handle C and C++ with the same heuristics.

Preferably for 3.3 too then.

-Andi

Re: GCC 3.3 release criteria

[Richard Earnshaw]

> > For functions marked with the "inline" keyword, as opposed to C++
> > inline class methods, can anyone give me a reason why we don't treat
> > the inline keyword as an always_inline attribute?
> 
> I wholeheartedly second that. If I write "inline" in C I expect that to happen 
> as soon as the optimizer is turned on. If there is room for even more 
> inlining after that, fine.
> So, for C "inline" should be mapped to "always_inline".

I think the inline keyword should be treated exactly in the same terms as 
the register keyword.  That is, as a hint to the compiler.  As time goes 
by the inline keyword will become increasingly meaningless, since the 
compiler will be able to do a better job.  Forcing the compiler to respect 
inline regardless of the consequences is a mistake.

R.

Re: GCC 3.3 release criteria

[Steven Bosscher]

Op di 25-02-2003, om 11:13 schreef Richard Earnshaw:
> 
> > > For functions marked with the "inline" keyword, as opposed to C++
> > > inline class methods, can anyone give me a reason why we don't treat
> > > the inline keyword as an always_inline attribute?
> > 
> > I wholeheartedly second that. If I write "inline" in C I expect that to happen 
> > as soon as the optimizer is turned on. If there is room for even more 
> > inlining after that, fine.
> > So, for C "inline" should be mapped to "always_inline".
> 
> I think the inline keyword should be treated exactly in the same terms as 
> the register keyword.  That is, as a hint to the compiler.  As time goes 
> by the inline keyword will become increasingly meaningless, since the 
> compiler will be able to do a better job.  Forcing the compiler to respect 
> inline regardless of the consequences is a mistake.

Yes the compiler will learn to do good inlining.  This is one of the
reasons why some people discourage the use of the inline keyword: Just
trust the compiler to do well.

You say that therefore the compiler should only use "inline" as a hint. 
I think it is *extra* reason to interpret "inline" as "always_inline".

Especially in C, people that do use "inline" probably have strong
reasons for why they want to see this function be inlined.   For example
in the kernel, they want to be able to control and predict what the
compiler does with the code.  It this case it is a mistake on the
compiler's part to think it can outsmart man.

Like Franz said, for C++ things are probalby different.

Greetz
Steven

Re: GCC 3.3 release criteria

[Richard Earnshaw]

> Op di 25-02-2003, om 11:13 schreef Richard Earnshaw:
> > 
> > > > For functions marked with the "inline" keyword, as opposed to C++
> > > > inline class methods, can anyone give me a reason why we don't treat
> > > > the inline keyword as an always_inline attribute?
> > > 
> > > I wholeheartedly second that. If I write "inline" in C I expect that to happen 
> > > as soon as the optimizer is turned on. If there is room for even more 
> > > inlining after that, fine.
> > > So, for C "inline" should be mapped to "always_inline".
> > 
> > I think the inline keyword should be treated exactly in the same terms as 
> > the register keyword.  That is, as a hint to the compiler.  As time goes 
> > by the inline keyword will become increasingly meaningless, since the 
> > compiler will be able to do a better job.  Forcing the compiler to respect 
> > inline regardless of the consequences is a mistake.
> 
> Yes the compiler will learn to do good inlining.  This is one of the
> reasons why some people discourage the use of the inline keyword: Just
> trust the compiler to do well.
> 
> You say that therefore the compiler should only use "inline" as a hint. 
> I think it is *extra* reason to interpret "inline" as "always_inline".
> 
> Especially in C, people that do use "inline" probably have strong
> reasons for why they want to see this function be inlined.   For example
> in the kernel, they want to be able to control and predict what the
> compiler does with the code.  It this case it is a mistake on the
> compiler's part to think it can outsmart man.
> 
> Like Franz said, for C++ things are probalby different.
> 

The cases in C where I've seen people get most upset about the compiler 
not using inline are when the program has subtly different semantics once 
inlining has occurred (for example, taking the address of a label and then 
using that as a key in a debug message).  But these are precisely the 
types of cases where we probably don't want inlining: relying on such 
optimization to get correct behaviour is a dangerous mistake.

Re: GCC 3.3 release criteria

[Gabriel Dos Reis]

Steven Bosscher <s.bosscher@student.tudelft.nl> writes:

[...]

| Especially in C, people that do use "inline" probably have strong
| reasons for why they want to see this function be inlined.   For example
| in the kernel, they want to be able to control and predict what the
| compiler does with the code.  It this case it is a mistake on the
| compiler's part to think it can outsmart man.

Since the introduction of "inline" in "C with classes" (circa 1981),
there regularly have been arguments along the line that the next
version of the compiler will be able to do much better than the
programmer and inline would be useless as a keyword.  Alas, more than
twenty years after, the practice is that the compiler still has issues
with inline.

Yes, I would really love to see GCC perform better in this area, but I'm
skeptical about the pratical goal of making the keyword "inline" mean
nothing but "may violate the ODR". 


-- Gaby

Re: GCC 3.3 release criteria

[Gabriel Dos Reis]

Richard Earnshaw <rearnsha@arm.com> writes:

[...]

| > Especially in C, people that do use "inline" probably have strong
| > reasons for why they want to see this function be inlined.   For example
| > in the kernel, they want to be able to control and predict what the
| > compiler does with the code.  It this case it is a mistake on the
| > compiler's part to think it can outsmart man.
| > 
| > Like Franz said, for C++ things are probalby different.
| > 
| 
| The cases in C where I've seen people get most upset about the compiler 
| not using inline are when the program has subtly different semantics once 
| inlining has occurred (for example, taking the address of a label and then 
| using that as a key in a debug message).  But these are precisely the 
| types of cases where we probably don't want inlining: relying on such 
| optimization to get correct behaviour is a dangerous mistake.

Agreed.  Ideally "inline" should not change the observable behaviour.
However, concerning "inline", ISO C99 has provided and blessed ways to
violate the ODR and to make "ready for changing semantics" :-(

-- Gaby

Re: GCC 3.3 release criteria

[Lars Segerlund]

  I just wanted to comment on the inline versus inline debate.

   When I write inline, I MEAN inline , and I generally have a VERY good
reason for it !

   I tend to do embedded system and regular system programming, and my
viewpoint is that the compilers reaction to 'inline' in not up to
interpretation, I do believe this is an opinion shared by a lot of
people doing real work.

   Inlining during optimisation is a separate issue, but as far as I am
concerned if this don't work as expected, I have to inline (either
automatically or by hand), and then include the .o files prodused by asm
sources.

   This would be quite a workaround.

   I think that somtimes 'high level' people don't quite understand the
issues involved when you have timing constraints on sections of code.

   / Lars Segerlund.

RE: GCC 3.3 release criteria

[Kean Johnston]

> I think the inline keyword should be treated exactly in the 
> same terms as the register keyword.  That is, as a hint to
> the compiler.  As time goes by the inline keyword will become
> increasingly meaningless, since the compiler will be able to
> do a better job.  Forcing the compiler to respect inline
> regardless of the consequences is a mistake.

I couldn't disagree more. I think that treating the register
keyword as just a hint is a mistake too. Granted, some people
liberally sprinkle their code with register keywords, and for
those situations, having the compiler make intelligent choices
about what actually goes in a register is appropriate, iff
there are not suffucient available registers to satisfy the
user's whims.

Having register / inline behave the way the programmer expects
it to gives the programmer the power of choice. There are
legitimate cases where the programmer *NEEDS* a variable in
a certain register, perhaps because of some inline assembly,
perhaps because they know that a function being called a
few insns down expects things that way ... for any number of
reasons. inline is exactly the same. The programmer may well
have established that some code really *DOES* need to be
inline, to provoke certain processor semantics, for precise
setting up of caches for testing, for any number of reasons.
If the compiler tries to outsmart the programmer and take
the power of choice away from them, that's bad.

I really believe in freedom of choice for the coder, as much
as is practical. By all means, have the compiler be smart.
Have it inline things where the user didn't make an explicit
choice. But always try and give the user an out, because at
some point in time you are guaranteed to have a situation
where the user is much much more knowledgeable about the
exact insn pattern they want than the compiler can ever be.

If you really do want to make inline just a hint, may I
suggest that you still leave the user an "out". The UnixWare
compiler has a novell (I *SO* nearly typed Novel) solution.
They have a #pragma that controls how aggressive the
optimizer is around inline assembly.  I forget the exact
syntax but its something along the lines of #pragma asm
{no_optimization | partial_optimization | full_optimization}.
I forget what the exact semantic differences between
partial and full are, but I do know that full_optimization
means that all the inline assembly is subject to the global
optimizer. I think partial_optimization means it wont
optimize the functions the asm is used in, but will
optimize everything else. Something like that. But you see
the point. It gives the user control.

Some other such mechanism, perhaps even one more generic
than just inline asms, could be invented so that the Linux
folks can have their inlines, and others who care less can
have inline treated as a hint. Perhaps something along
the lines of #pragma always_inline (and by the same
token #pragma always_register) would be in order. Or even
a #pragma obey_modifier {register | inline | any_other_hint}
would do the trick.

Sorry for rambling. Give the power to the coder.

Kean

Re: GCC 3.3 release criteria

[Franz Sirl]

At 11:13 25.02.2003, Richard Earnshaw wrote:

> > > For functions marked with the "inline" keyword, as opposed to C++
> > > inline class methods, can anyone give me a reason why we don't treat
> > > the inline keyword as an always_inline attribute?
> >
> > I wholeheartedly second that. If I write "inline" in C I expect that to 
> happen
> > as soon as the optimizer is turned on. If there is room for even more
> > inlining after that, fine.
> > So, for C "inline" should be mapped to "always_inline".
>
>I think the inline keyword should be treated exactly in the same terms as
>the register keyword.  That is, as a hint to the compiler.  As time goes
>by the inline keyword will become increasingly meaningless, since the
>compiler will be able to do a better job.  Forcing the compiler to respect
>inline regardless of the consequences is a mistake.

If you want to change the inline behaviour, you need first to deprecate 
with a warning the currently documented behaviour (in 3.2/3.3) and then 
change inline to a hint in 3.4.

But the current behaviour violates the documentation (where size isn't a 
criteria for non-inlining) and thus is a bug. Note that even -Winline 
doesn't work as documented, it doesn't give a reason.

Franz.

Re: GCC 3.3 release criteria

[Richard Earnshaw]

> Richard Earnshaw <rearnsha@arm.com> writes:
> 
> [...]
> 
> | > Especially in C, people that do use "inline" probably have strong
> | > reasons for why they want to see this function be inlined.   For example
> | > in the kernel, they want to be able to control and predict what the
> | > compiler does with the code.  It this case it is a mistake on the
> | > compiler's part to think it can outsmart man.
> | > 
> | > Like Franz said, for C++ things are probalby different.
> | > 
> | 
> | The cases in C where I've seen people get most upset about the compiler 
> | not using inline are when the program has subtly different semantics once 
> | inlining has occurred (for example, taking the address of a label and then 
> | using that as a key in a debug message).  But these are precisely the 
> | types of cases where we probably don't want inlining: relying on such 
> | optimization to get correct behaviour is a dangerous mistake.
> 
> Agreed.  Ideally "inline" should not change the observable behaviour.
> However, concerning "inline", ISO C99 has provided and blessed ways to
> violate the ODR and to make "ready for changing semantics" :-(

We have to be fairly careful here, since we are dealing with 3 different 
specifications of "inline": GNU (pre-c99), C99 and C++.  I'm not 
particularly familiar with the subtleties of all three.

C99 says (6.7.4par5):

 ... Making a function an inline function suggests that calls to the
 function be as fast as possible.  The extent to which such suggestions are
 effective is implementation defined.

Note two things.  Firstly, this is only a "suggestion".  Secondly, since 
an implementation is free to ignore such a request any code that relies on 
honouring the request for correct behaviour must be ill-formed.

R.

Re: GCC 3.3 release criteria

[Gabriel Dos Reis]

Richard Earnshaw <rearnsha@arm.com> writes:

| > Richard Earnshaw <rearnsha@arm.com> writes:
| > 
| > [...]
| > 
| > | > Especially in C, people that do use "inline" probably have strong
| > | > reasons for why they want to see this function be inlined.   For example
| > | > in the kernel, they want to be able to control and predict what the
| > | > compiler does with the code.  It this case it is a mistake on the
| > | > compiler's part to think it can outsmart man.
| > | > 
| > | > Like Franz said, for C++ things are probalby different.
| > | > 
| > | 
| > | The cases in C where I've seen people get most upset about the compiler 
| > | not using inline are when the program has subtly different semantics once 
| > | inlining has occurred (for example, taking the address of a label and then 
| > | using that as a key in a debug message).  But these are precisely the 
| > | types of cases where we probably don't want inlining: relying on such 
| > | optimization to get correct behaviour is a dangerous mistake.
| > 
| > Agreed.  Ideally "inline" should not change the observable behaviour.
| > However, concerning "inline", ISO C99 has provided and blessed ways to
| > violate the ODR and to make "ready for changing semantics" :-(
| 
| We have to be fairly careful here, since we are dealing with 3 different 
| specifications of "inline": GNU (pre-c99), C99 and C++.  I'm not 
| particularly familiar with the subtleties of all three.
| 
| C99 says (6.7.4par5):
| 
|  ... Making a function an inline function suggests that calls to the
|  function be as fast as possible.  The extent to which such suggestions are
|  effective is implementation defined.
| 
| Note two things.  Firstly, this is only a "suggestion".  Secondly, since 
| an implementation is free to ignore such a request any code that relies on 
| honouring the request for correct behaviour must be ill-formed.

then, do we plan to issue a diagnostic?

To extend my original comment, here are pieaces where C99 blesses ODR
violation:

6.7.4/6
  [...] An inline definition does not provide an external definition
  for the function, and does not forbid an external definition in
  another translation unit.  An inline definition  provides an
  alternative to an external definition, which a translator may use to
  implement any call to the function  in  the  same translation  unit.
  It is unspecified whether a call to the function  uses  the  inline
  definition  or   the   external definition. 


I agree that ideally, C programs should not depend on inlining for
correctness, but in practice that seems to happen more than often.

-- Gaby

Re: GCC 3.3 release criteria

[Andreas Schwab]

"Kean Johnston" <jkj@sco.com> writes:

|> Having register / inline behave the way the programmer expects
|> it to gives the programmer the power of choice. There are
|> legitimate cases where the programmer *NEEDS* a variable in
|> a certain register

If you need a certain register, use __asm__("reg").  Everything else is
calling for trouble.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GCC 3.3 release criteria

[Richard Earnshaw]

> | We have to be fairly careful here, since we are dealing with 3 different 
> | specifications of "inline": GNU (pre-c99), C99 and C++.  I'm not 
> | particularly familiar with the subtleties of all three.
> | 
> | C99 says (6.7.4par5):
> | 
> |  ... Making a function an inline function suggests that calls to the
> |  function be as fast as possible.  The extent to which such suggestions are
> |  effective is implementation defined.
> | 
> | Note two things.  Firstly, this is only a "suggestion".  Secondly, since 
> | an implementation is free to ignore such a request any code that relies on 
> | honouring the request for correct behaviour must be ill-formed.
> 
> then, do we plan to issue a diagnostic?

There are a lot of ill-formed (note I don't use other terms like 
undefined) programs for which it is impossible to emit a diagnostic.  The 
following, for example is ill-formed, though each statement is 
well-defined.

int x;
int plus_x() { x+=1; return x;}
int get_x() {return x;}
extern int f(int, int);
int g()
{ return g(plus_x(), get_x();}

In general, programmers just have to know how to avoid such constructs, 
since it is not generally possible for the compiler to diagnose them.
  
> 
> To extend my original comment, here are pieaces where C99 blesses ODR
> violation:
> 
> 6.7.4/6
>   [...] An inline definition does not provide an external definition
>   for the function, and does not forbid an external definition in
>   another translation unit.  An inline definition  provides an
>   alternative to an external definition, which a translator may use to
>   implement any call to the function  in  the  same translation  unit.
>   It is unspecified whether a call to the function  uses  the  inline
>   definition  or   the   external definition. 
> 

I think that statement requires careful interpretation.  As I see it, the 
intent is to make it clear that the inline definition only leads to an 
external definition if a redeclaration with "extern" is provided.  It 
doesn't, for example, permit a second compilation unit to provide a second 
extern definition, or for separate compilation units to use different 
definitions of the body of the inline function.  I do think it could have 
said things more clearly though.

> 
> I agree that ideally, C programs should not depend on inlining for
> correctness, but in practice that seems to happen more than often.

In that we are not in disagreement.

R.

Re: GCC 3.3 release criteria

[Richard Earnshaw]

> There are a lot of ill-formed (note I don't use other terms like 
> undefined) programs for which it is impossible to emit a diagnostic.  The 
> following, for example is ill-formed, though each statement is 
> well-defined.
> 
> int x;
> int plus_x() { x+=1; return x;}
> int get_x() {return x;}
> extern int f(int, int);
> int g()
> { return g(plus_x(), get_x();}

Err, before the pedants start, that last line should read:

{return f(plus_x(), get_x());}

Re: GCC 3.3 release criteria

[Gabriel Dos Reis]

Richard Earnshaw <rearnsha@arm.com> writes:

| > | We have to be fairly careful here, since we are dealing with 3 different 
| > | specifications of "inline": GNU (pre-c99), C99 and C++.  I'm not 
| > | particularly familiar with the subtleties of all three.
| > | 
| > | C99 says (6.7.4par5):
| > | 
| > |  ... Making a function an inline function suggests that calls to the
| > |  function be as fast as possible.  The extent to which such suggestions are
| > |  effective is implementation defined.
| > | 
| > | Note two things.  Firstly, this is only a "suggestion".  Secondly, since 
| > | an implementation is free to ignore such a request any code that relies on 
| > | honouring the request for correct behaviour must be ill-formed.
| > 
| > then, do we plan to issue a diagnostic?
| 
| There are a lot of ill-formed (note I don't use other terms like 
| undefined) programs for which it is impossible to emit a diagnostic.

The reason I was asking is that, by default, if a program is nominated
"ill-formed" then a diagnostic is required unless that nomiation is
followed by the mention "no diagnostic is required".  My question was not
meant to imply that I was actively proposing to issue diagnostic (or the
contrary), but merely to query your position on that matter.

[...]

| > To extend my original comment, here are pieaces where C99 blesses ODR
| > violation:
| > 
| > 6.7.4/6
| >   [...] An inline definition does not provide an external definition
| >   for the function, and does not forbid an external definition in
| >   another translation unit.  An inline definition  provides an
| >   alternative to an external definition, which a translator may use to
| >   implement any call to the function  in  the  same translation  unit.
| >   It is unspecified whether a call to the function  uses  the  inline
| >   definition  or   the   external definition. 
| > 
| 
| I think that statement requires careful interpretation.  As I see it, the 
| intent is to make it clear that the inline definition only leads to an 
| external definition if a redeclaration with "extern" is provided.  It 
| doesn't, for example, permit a second compilation unit to provide a second 
| extern definition, or for separate compilation units to use different 
| definitions of the body of the inline function.  I do think it could have 
| said things more clearly though.

Well, that interpretation is  not that clear since that paragraph
specifically says the inline definition is an *alternative* to an
external definition.  Clearly, a second translation unit may provide
a (second) external definition.

| > I agree that ideally, C programs should not depend on inlining for
| > correctness, but in practice that seems to happen more than often.
| 
| In that we are not in disagreement.

OK.

-- Gaby

Re: GCC 3.3 release criteria

[Richard Earnshaw]

> | There are a lot of ill-formed (note I don't use other terms like 
> | undefined) programs for which it is impossible to emit a diagnostic.
> 
> The reason I was asking is that, by default, if a program is nominated
> "ill-formed" then a diagnostic is required unless that nomiation is
> followed by the mention "no diagnostic is required".  My question was not
> meant to imply that I was actively proposing to issue diagnostic (or the
> contrary), but merely to query your position on that matter.
> 
> [...]

It's instructive to read the draft c99 rationale on this topic

	http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/docs/n897.pdf

They use the term "unspecified behaviour" which is probably the best one.  
Unspecified behaviour can be "two or more possibilities" and the 
implementation can chose any one on a case-by-case basis.

> 
> | > To extend my original comment, here are pieaces where C99 blesses ODR
> | > violation:
> | > 
> | > 6.7.4/6
> | >   [...] An inline definition does not provide an external definition
> | >   for the function, and does not forbid an external definition in
> | >   another translation unit.  An inline definition  provides an
> | >   alternative to an external definition, which a translator may use to
> | >   implement any call to the function  in  the  same translation  unit.
> | >   It is unspecified whether a call to the function  uses  the  inline
> | >   definition  or   the   external definition. 
> | > 
> | 
> | I think that statement requires careful interpretation.  As I see it, the 
> | intent is to make it clear that the inline definition only leads to an 
> | external definition if a redeclaration with "extern" is provided.  It 
> | doesn't, for example, permit a second compilation unit to provide a second 
> | extern definition, or for separate compilation units to use different 
> | definitions of the body of the inline function.  I do think it could have 
> | said things more clearly though.
> 
> Well, that interpretation is  not that clear since that paragraph
> specifically says the inline definition is an *alternative* to an
> external definition.  Clearly, a second translation unit may provide
> a (second) external definition.

Right, but it doesn't say that the definitions can be different; and it 
doesn't allow two or more translation units to provide an extern 
definition, even if they are identical.  Again, the rationale seems to 
clarify things significantly.


R.

Re: GCC 3.3 release criteria

[Fergus Henderson]

On 25-Feb-2003, Richard Earnshaw <rearnsha@arm.com> wrote:
> 
> > Well, that interpretation is  not that clear since that paragraph
> > specifically says the inline definition is an *alternative* to an
> > external definition.  Clearly, a second translation unit may provide
> > a (second) external definition.
> 
> Right, but it doesn't say that the definitions can be different;

The intent is certainly that the definitions can be different.
I know because I was involved in the committee discussions on this one.

Allowing the definitions to be different is needed to permit cases such
the use of assert() in an inline function in a header file which gets
included in different translation units with different settings of NDEBUG.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: Inlining (was: GCC 3.3 release criteria)

[Matt Austern]

On Monday, February 24, 2003, at 07:20 PM, Tolga Dalman wrote:

>> We definitely don't want -fobey-inline to be the default: usually it's
>> better for the compiler to treat the inline keyword as a hint, and to
>> use its own heuristics to decide when to accept the hint.  But there 
>> are
>> cases, as you've found, when a flag like this is useful.
>>
>
> this confuses me a bit. i always thought, that the "inline" keyword 
> would
> in any case force inlining, except for the -fno-inline flag activated.
> IMHO, the compiler should always obey user inlining, because the 
> compiler
> should trust the programmer when he uses an optional feature (such as 
> inline).
> for me, the question evolves: what does happen in -Os optimization? i 
> suppose,
> there isn't done any inline at all, not even explicitely "inline" 
> marked
> functions, no?

Some programmers have the expectation that the compiler will always 
inline
everything that's marked inline.  Other programmers very definitely do 
not
expect that, and write code where 'inline' is treated merely as a hint 
to the
compiler: marking a function 'inline' means you're telling the compiler 
that
you won't mind if it chooses to inline the function.

(Inline-as-hint is what the C++ Standard says, for what it's worth.  I 
don't know
the C99 standard as well.)

Empirically, treating 'inline' as a directive rather than a hint will 
make a lot
of programs much worse.  This isn't conjecture.  We did the measurement 
at
Apple.  -fobey-inline is occasionally useful, but making it the default 
would be
disastrous.

In the end I expect that more and more compilers will choose to ignore 
the
'inline' keyword entirely.  They'll treat it the same way as 
'register', and for
the same reason: a sufficiently clever optimizer has more information 
than
the programmer does, and can do a better job of knowing which functions
should be inlined.  Some optimizers are already good enough so that's 
true.
Our optimizer isn't (yet), but that's where we eventually want to be.

			--Matt

Re: GCC 3.3 release criteria

[Joseph S. Myers]

On Tue, 25 Feb 2003, Richard Earnshaw wrote:

> > There are a lot of ill-formed (note I don't use other terms like 
> > undefined) programs for which it is impossible to emit a diagnostic.  The 
> > following, for example is ill-formed, though each statement is 
> > well-defined.
> > 
> > int x;
> > int plus_x() { x+=1; return x;}
> > int get_x() {return x;}
> > extern int f(int, int);
> > int g()
> > { return g(plus_x(), get_x();}
> 
> Err, before the pedants start, that last line should read:
> 
> {return f(plus_x(), get_x());}

What is meant to be wrong with this code?  There isn't a sequence point
problem: function calls do not overlap (DR#087; C++ states this
explicitly).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC 3.3 release criteria

[tm_gccmail]

On Tue, 25 Feb 2003, Lars Segerlund wrote:

> 
>   I just wanted to comment on the inline versus inline debate.
> 
>    When I write inline, I MEAN inline , and I generally have a VERY good
> reason for it !
> 
>    I tend to do embedded system and regular system programming, and my
> viewpoint is that the compilers reaction to 'inline' in not up to
> interpretation, I do believe this is an opinion shared by a lot of
> people doing real work.
> 
>    Inlining during optimisation is a separate issue, but as far as I am
> concerned if this don't work as expected, I have to inline (either
> automatically or by hand), and then include the .o files prodused by asm
> sources.
> 
>    This would be quite a workaround.
> 
>    I think that somtimes 'high level' people don't quite understand the
> issues involved when you have timing constraints on sections of code.
> 
>    / Lars Segerlund.

My feelings exactly...for embedded programming and kernel work, you need
an inline keyword that consistently inlines, regardless of the setting of
the compiler switches or whatever.

This has been reiterated a lot, but evidently it's not enough. We need
reliable inlining facilities.

Toshi

Re: Inlining (was: GCC 3.3 release criteria)

[Tolga Dalman]

On Tue, 25 Feb 2003 09:59:52 -0800 Matt Austern <austern@apple.com> wrote:

> On Monday, February 24, 2003, at 07:20 PM, Tolga Dalman wrote:
> 
> >> We definitely don't want -fobey-inline to be the default: usually it's
> >> better for the compiler to treat the inline keyword as a hint, and to
> >> use its own heuristics to decide when to accept the hint.  But there 
> >> are
> >> cases, as you've found, when a flag like this is useful.
> >>
> >
> > this confuses me a bit. i always thought, that the "inline" keyword 
> > would
> > in any case force inlining, except for the -fno-inline flag activated.
> > IMHO, the compiler should always obey user inlining, because the 
> > compiler
> > should trust the programmer when he uses an optional feature (such as 
> > inline).
> > for me, the question evolves: what does happen in -Os optimization? i 
> > suppose,
> > there isn't done any inline at all, not even explicitely "inline" 
> > marked
> > functions, no?
> 
> Some programmers have the expectation that the compiler will always 
> inline
> everything that's marked inline.  Other programmers very definitely do 
> not
> expect that, and write code where 'inline' is treated merely as a hint 
> to the
> compiler: marking a function 'inline' means you're telling the compiler 
> that
> you won't mind if it chooses to inline the function.
> 

yeah, but i'm not able to say "definitively: don't compile this function as
inlined one!", neither saying "inline" nor saying "don't inline" is then
possible.

> (Inline-as-hint is what the C++ Standard says, for what it's worth.  I 
> don't know
> the C99 standard as well.)
> 
> Empirically, treating 'inline' as a directive rather than a hint will 
> make a lot
> of programs much worse.  This isn't conjecture.  We did the measurement 
> at
> Apple.  -fobey-inline is occasionally useful, but making it the default 
> would be
> disastrous.
> 

i understand. IMHO, gcc _should_ deprecate the ISO-C qualifiers inline and
register then , since they are not usable in an appropriate way. doing so, gcc
could "educate" a programmer _not_ to use these keywords, even though they're
defined in the standard. 

> In the end I expect that more and more compilers will choose to ignore 
> the
> 'inline' keyword entirely.  They'll treat it the same way as 
> 'register', and for
> the same reason: a sufficiently clever optimizer has more information 
> than
> the programmer does, and can do a better job of knowing which functions
> should be inlined.  Some optimizers are already good enough so that's 
> true.
> Our optimizer isn't (yet), but that's where we eventually want to be.

but that's not the point: from my point of view as "user", i want to be able to
disable inlining entirely except for those functions i explicitely mark (via
-Os for example). or the other way round: i want to inline everything (with a
certain threshold of course), except for a few function that never should be
inlined. 
i believe, the standard inlining algorithms are very good, but gcc (rather the
standard itself) makes finetuning impossible. please correct me, if i was wrong.

brg, 
Tolga.

Re: Inlining (was: GCC 3.3 release criteria)

[Michel LESPINASSE]

On Tue, Feb 25, 2003 at 09:59:52AM -0800, Matt Austern wrote:

> Some programmers have the expectation that the compiler will always
> inline everything that's marked inline.  Other programmers very
> definitely do not expect that, and write code where 'inline' is
> treated merely as a hint to the compiler: marking a function
> 'inline' means you're telling the compiler that you won't mind if it
> chooses to inline the function.

In my experience, most C programmers expect inline to inline, while
C++ programmers dont.

> (Inline-as-hint is what the C++ Standard says, for what it's worth.
> I don't know the C99 standard as well.)

I'm not sure about C99 - my understanding is that the compiler is
allowed to ignore the inline keyword but most C programmers dont
expect it to.

> Empirically, treating 'inline' as a directive rather than a hint
> will make a lot of programs much worse.  This isn't conjecture.  We
> did the measurement at Apple.  -fobey-inline is occasionally useful,
> but making it the default would be disastrous.

Just to be clear: were these C programs or C++ ?

> In the end I expect that more and more compilers will choose to
> ignore the 'inline' keyword entirely.  They'll treat it the same way
> as 'register', and for the same reason: a sufficiently clever
> optimizer has more information than the programmer does, and can do
> a better job of knowing which functions should be inlined.  Some
> optimizers are already good enough so that's true.  Our optimizer
> isn't (yet), but that's where we eventually want to be.

I kinda agree that using 'register' today would be idiotic, as
compilers are pretty good at making that choice already. And I hope
gcc will get there with 'inline' as well eventually. But frankly,
today, gcc's inlining just sucks for C programmers. The inline keyword
is not as satisfying as a smart compiler heuristic might be, but it's
much nicer than what we have today.

Cheers,

-- 
Michel "Walken" LESPINASSE
Is this the best that god can do ? Then I'm not impressed.

Re: GCC 3.3 release criteria

[Michael Hayes]

tm_gccmail@mail.kloo.net writes:

 > My feelings exactly...for embedded programming and kernel work, you need
 > an inline keyword that consistently inlines, regardless of the setting of
 > the compiler switches or whatever.

I endorse this for small-scale embedded apps where you want the
convenience of a function call abstraction but not the expense of a
call instruction---some micros only have an 8 level call stack!

For general programming, I'm happy to defer to the wisdom of the
compiler.


Michael.

Re: GCC 3.3 release criteria

[Matt Austern]

On Tuesday, February 25, 2003, at 12:51  PM, Michael Hayes wrote:

> tm_gccmail@mail.kloo.net writes:
>
>> My feelings exactly...for embedded programming and kernel work, you 
>> need
>> an inline keyword that consistently inlines, regardless of the 
>> setting of
>> the compiler switches or whatever.
>
> I endorse this for small-scale embedded apps where you want the
> convenience of a function call abstraction but not the expense of a
> call instruction---some micros only have an 8 level call stack!
>
> For general programming, I'm happy to defer to the wisdom of the
> compiler.

This sounds like an argument in favor of a switch like Apple's
-fobey-inline.  Programmers who are writing specialized code
and who need detailed control of low-level optimizations will
use that switch, others won't.

Again, I should remind people: Apple tried the experiment of
making -fobey-inline the default.  The results were not good.
This sort of low-level control is sometimes useful, but it's
not useful as often as a lot of people think it is.  If we
do make -fobey-inline available (which I think we should),
then I encourage everyone to compile their code with and
without it, and look at the effect on code size, before adding
it to their makefiles.

			--Matt

Re: Inlining (was: GCC 3.3 release criteria)

[Timothy J. Wood]

On Tuesday, February 25, 2003, at 09:59  AM, Matt Austern wrote:
> Empirically, treating 'inline' as a directive rather than a hint will 
> make a lot
> of programs much worse.  This isn't conjecture.  We did the 
> measurement at
> Apple.  -fobey-inline is occasionally useful, but making it the 
> default would be
> disastrous.

   You could make -Winline be on by default instead.  This would let the 
compiler make the choice and would warn if an function was marked 
inline and the compiler disagreed with you (hopefully saying *why* it 
disagreed).

   This would help people get rid of extra 'inline' keywords and once 
that was done, they'd have a better chance of turning on -fobey-inline 
without terrible results (and presumably -fobey-inline would imply 
-Winline).

-tim

Re: GCC 3.3 release criteria

[tm_gccmail]

On Tue, 25 Feb 2003, Matt Austern wrote:

> On Tuesday, February 25, 2003, at 12:51  PM, Michael Hayes wrote:
> 
> > tm_gccmail@mail.kloo.net writes:
> >
> >> My feelings exactly...for embedded programming and kernel work, you 
> >> need
> >> an inline keyword that consistently inlines, regardless of the 
> >> setting of
> >> the compiler switches or whatever.
> >
> > I endorse this for small-scale embedded apps where you want the
> > convenience of a function call abstraction but not the expense of a
> > call instruction---some micros only have an 8 level call stack!
> >
> > For general programming, I'm happy to defer to the wisdom of the
> > compiler.
> 
> This sounds like an argument in favor of a switch like Apple's
> -fobey-inline.  Programmers who are writing specialized code
> and who need detailed control of low-level optimizations will
> use that switch, others won't.
> 
> Again, I should remind people: Apple tried the experiment of
> making -fobey-inline the default.  The results were not good.
> This sort of low-level control is sometimes useful, but it's
> not useful as often as a lot of people think it is.  If we
> do make -fobey-inline available (which I think we should),
> then I encourage everyone to compile their code with and
> without it, and look at the effect on code size, before adding
> it to their makefiles.
> 
> 			--Matt

I think the "always_inline" attribute is enough, as long as it does
actually always inline regardless of the options.

It would be nice to have:

"maybe_inline" as a compiler hinting mechanism
"never_inline" to force the compiler not to inline
                   (for debugging purpose and whatnot) 

Toshi

Re: GCC 3.3 release criteria

[Stuart Hastings]

On Tuesday, Feb 25, 2003, at 13:00 US/Pacific, Matt Austern wrote:

> On Tuesday, February 25, 2003, at 12:51  PM, Michael Hayes wrote:
>
>> tm_gccmail@mail.kloo.net writes:
>>
>>> My feelings exactly...for embedded programming and kernel work, you 
>>> need
>>> an inline keyword that consistently inlines, regardless of the 
>>> setting of
>>> the compiler switches or whatever.
>>
>> I endorse this for small-scale embedded apps where you want the
>> convenience of a function call abstraction but not the expense of a
>> call instruction---some micros only have an 8 level call stack!
>>
>> For general programming, I'm happy to defer to the wisdom of the
>> compiler.
>
> This sounds like an argument in favor of a switch like Apple's
> -fobey-inline.  Programmers who are writing specialized code
> and who need detailed control of low-level optimizations will
> use that switch, others won't.
>
> Again, I should remind people: Apple tried the experiment of
> making -fobey-inline the default.  The results were not good.

Specifically, indiscriminate use can provoke significant code bloat.

> This sort of low-level control is sometimes useful, but it's
> not useful as often as a lot of people think it is.

<platitude>
Like any tool, it can be misused.
</platitude>

> If we do make -fobey-inline available (which I think we should),
> then I encourage everyone to compile their code with and
> without it, and look at the effect on code size, before adding
> it to their makefiles.

Granted the evident interest, I will dust off "-fobey-inline", 
regression-test it, and offer a patch.

stuart hastings
Apple Computer

Re: GCC 3.3 release criteria

[Christoph Hellwig]

On Tue, Feb 25, 2003 at 01:00:17PM -0800, Matt Austern wrote:
> not useful as often as a lot of people think it is.  If we
> do make -fobey-inline available (which I think we should),
> then I encourage everyone to compile their code with and
> without it, and look at the effect on code size, before adding
> it to their makefiles.

It should be the default for gnu89 mode in the C frontend because
that's what existing code expects.  Silently changing semantics is
not a very good idea if it can be avoided.

Re: GCC 3.3 release criteria

[Matt Austern]

On Tuesday, February 25, 2003, at 02:07  PM, Christoph Hellwig wrote:

> On Tue, Feb 25, 2003 at 01:00:17PM -0800, Matt Austern wrote:
>> not useful as often as a lot of people think it is.  If we
>> do make -fobey-inline available (which I think we should),
>> then I encourage everyone to compile their code with and
>> without it, and look at the effect on code size, before adding
>> it to their makefiles.
>
> It should be the default for gnu89 mode in the C frontend because
> that's what existing code expects.  Silently changing semantics is
> not a very good idea if it can be avoided.

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.

			--Matt

Re: GCC 3.3 release criteria

[Michel LESPINASSE]

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.

Cheers,

-- 
Michel "Walken" LESPINASSE
Is this the best that god can do ? Then I'm not impressed.

Re: GCC 3.3 release criteria

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GCC 3.3 release criteria

[Matt Austern]

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

Re: GCC 3.3 release criteria

[Dale Johannesen]

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.

Re: GCC 3.3 release criteria

[Richard Henderson]

On Tue, Feb 25, 2003 at 02:03:49PM -0800, Stuart Hastings wrote:
> Granted the evident interest, I will dust off "-fobey-inline", 
> regression-test it, and offer a patch.

I'd rather not.  We already have attribute(always_inline)
that can force inlining, and it's not as indiscriminate as
a whole-translation-unit switch.


r~

Re: GCC 3.3 release criteria

[Richard Henderson]

On Tue, Feb 25, 2003 at 02:37:22PM -0800, tm_gccmail@mail.kloo.net wrote:
> "maybe_inline" as a compiler hinting mechanism

What's the point?

> "never_inline" to force the compiler not to inline
>                    (for debugging purpose and whatnot) 

We already have this.


r~

Re: GCC 3.3 release criteria

[Richard Henderson]

On Tue, Feb 25, 2003 at 12:55:53PM +0100, Franz Sirl wrote:
> >I think the inline keyword should be treated exactly in the same terms as
> >the register keyword.  That is, as a hint to the compiler.  As time goes
> >by the inline keyword will become increasingly meaningless, since the
> >compiler will be able to do a better job.  Forcing the compiler to respect
> >inline regardless of the consequences is a mistake.
> 
> If you want to change the inline behaviour, you need first to deprecate 
> with a warning the currently documented behaviour (in 3.2/3.3) and then 
> change inline to a hint in 3.4.

Huh?  No, "inline" was *always* only a suggestion.  We've just
changed the heuristics involved in the choice.


r~

Re: Inlining (was: GCC 3.3 release criteria)

[Gabriel Dos Reis]

Matt Austern <austern@apple.com> writes:

[...]

| Apple.  -fobey-inline is occasionally useful, but making it the
| default would be
| disastrous.

Does -fobey-inline differ from __attribute__((always_inline))?

-- Gaby

Re: Inlining (was: GCC 3.3 release criteria)

[Olivier Galibert]

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.

  OG.

Re: Inlining (was: GCC 3.3 release criteria)

[Gabriel Dos Reis]

Olivier Galibert <galibert@pobox.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.

-- Gaby

Re: GCC 3.3 release criteria

[Mattias Engdegård]

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

In releases prior to 3.3, inline functions aren't even as fast as macros.
I found out this when converting a bunch of hairy macros to inline functions.
In the cases I tested, gcc 3.3 generated the same code for the macro case
and inline functions, so this has apparently been solved.

A common coding style (at least around here) is to write rather big
and complex inline functions (frequently containing calls to other big
inline functions), assuming that they will collapse to relatively
little code when instantiated, because of constant folding and
dead-code removal. Quite often the resulting code is smaller than the
function call to a non-inlined function.

A -fobey-inline directive sounds like a good compromise for 3.3.

Re: Inlining (was: GCC 3.3 release criteria)

[Allan Sandfeld]

On Wednesday 26 February 2003 11:44, Gabriel Dos Reis wrote:
> Olivier Galibert <galibert@pobox.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.
>
I guess this is what -fobey-inline does internally. The difference is that 
-fobey-inline makes immediate sense, and is a regular flag we can document in 
man and info. IOW people will know it's possible and use it.

`Allan

Re: GCC 3.3 release criteria

[Bernd Schmidt]

On Tue, 25 Feb 2003, Richard Earnshaw wrote:

> The cases in C where I've seen people get most upset about the compiler 
> not using inline are when the program has subtly different semantics once 
> inlining has occurred (for example, taking the address of a label and then 
> using that as a key in a debug message).  But these are precisely the 
> types of cases where we probably don't want inlining: relying on such 
> optimization to get correct behaviour is a dangerous mistake.

I was rather upset when I discovered the inline keyword was no longer
honoured by gcc.  One of my applications uses inlining to reduce code
duplication without hurting performance.  I have a few time-critical
functions of the form

inline void f (int arg1, int arg2, int arg3)
{
   ... several loops deep..
   {
       if (arg1 == 1)
	  foo;
       else
	  bar;
   }
}

I know the range of the values the arguments can have, and I use inlining
to move the tests out of the loops without having to duplicate all the
loop bodies by hand.

I have 
  void f_2_3_1 () { f (2, 3, 1); }
etc. (these will expand into optimized versions of f) as well as a frontend
function that takes arg1, arg2 and arg3 and decides which of the f_x_y_z
to call.

The effect is maybe slightly similar to C++ templates.  Needless to say,
it completely fell apart with gcc-3.0 which decided it was smarter than
the programmer.

I would like something like -fobey-inline to be the default.


Bernd

Re: GCC 3.3 release criteria

[Richard Earnshaw]

> On Tue, 25 Feb 2003, Richard Earnshaw wrote:
> 
> > The cases in C where I've seen people get most upset about the compiler 
> > not using inline are when the program has subtly different semantics once 
> > inlining has occurred (for example, taking the address of a label and then 
> > using that as a key in a debug message).  But these are precisely the 
> > types of cases where we probably don't want inlining: relying on such 
> > optimization to get correct behaviour is a dangerous mistake.
> 
> I was rather upset when I discovered the inline keyword was no longer
> honoured by gcc.  One of my applications uses inlining to reduce code
> duplication without hurting performance.  I have a few time-critical
> functions of the form
> 
> inline void f (int arg1, int arg2, int arg3)
> {
>    ... several loops deep..
>    {
>        if (arg1 == 1)
> 	  foo;
>        else
> 	  bar;
>    }
> }
> 
> I know the range of the values the arguments can have, and I use inlining
> to move the tests out of the loops without having to duplicate all the
> loop bodies by hand.
> 
> I have 
>   void f_2_3_1 () { f (2, 3, 1); }
> etc. (these will expand into optimized versions of f) as well as a frontend
> function that takes arg1, arg2 and arg3 and decides which of the f_x_y_z
> to call.
> 
> The effect is maybe slightly similar to C++ templates.  Needless to say,
> it completely fell apart with gcc-3.0 which decided it was smarter than
> the programmer.
> 
> I would like something like -fobey-inline to be the default.

What's really needed is to make gcc's inlining heuristics smarter, not to 
provide a crowbar which rides roughshod over everything.

For example, gcc's inlining metrics should probably take into account the 
number of constants that are passed as arguments to a function 
(particularly if it could be made to see that such arguments are used in a 
manner that would fold conditional expressions).

Also remember that what's good as an inline function on one architecture 
might be terrible on another (for example, because it leads to excessive 
spilling).

R.

Re: Inlining (was: GCC 3.3 release criteria)

[Andi Kleen]

> >But then if -fobey-inline doesn't error then there is something about 
> >it?
> >
> >Matt, what does happen when a function can't be inlined?
> 
> Nothing special.  It inlines the function if possible; if not (e.g. if 
> it's a
> recursive call), then it just silently doesn't do the inlining.

That's exactly the semantics I want too. It would be nice if your patch
could be put into gcc 3.3

-Andi

Re: Inlining (was: GCC 3.3 release criteria)

[Matt Austern]

On Wednesday, February 26, 2003, at 03:52 AM, Gabriel Dos Reis wrote:

> Andi Kleen <ak@suse.de> writes:
>
> | > | forces -Werror -Winline
> | >
> | > Why so?
> |
> | always_inline errors when the function cannot get inlined.
>
> Thanks for the education and your patience.
>
> But then if -fobey-inline doesn't error then there is something about 
> it?
>
> Matt, what does happen when a function can't be inlined?

Nothing special.  It inlines the function if possible; if not (e.g. if 
it's a
recursive call), then it just silently doesn't do the inlining.

			--matt

Re: Inlining (was: GCC 3.3 release criteria)

[Gabriel Dos Reis]

Andi Kleen <ak@suse.de> writes:

| > | forces -Werror -Winline
| > 
| > Why so?
| 
| always_inline errors when the function cannot get inlined.

Thanks for the education and your patience.

But then if -fobey-inline doesn't error then there is something about it?

Matt, what does happen when a function can't be inlined?

-- Gaby

Re: Inlining (was: GCC 3.3 release criteria)

[Andi Kleen]

> | forces -Werror -Winline
> 
> Why so?

always_inline errors when the function cannot get inlined.

(the -Werror in my example only applies to the -Winline warning)

-Andi

Re: Inlining (was: GCC 3.3 release criteria)

[Gabriel Dos Reis]

Andi Kleen <ak@suse.de> writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
| > Olivier Galibert <galibert@pobox.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

Well, -fobey-inline is also  semantics change to older compilers.

| forces -Werror -Winline

Why so?

-- Gaby

Re: Inlining (was: GCC 3.3 release criteria)

[Andi Kleen]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> Olivier Galibert <galibert@pobox.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