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: GCC 3.3 release criteria

[Kaveh R. Ghazi]

 > From: Janis Johnson <janis187@us.ibm.com>
 > 
 > There ought to be separate categories for testers (people who are doing
 > regular bootstraps, regression test runs, and running application tests)
 > and fixers.  Even if there's not a fixer, it's useful to know that
 > someone is testing the platform and reporting problems.
 > Janis

That sounds like an excellent idea.

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

Re: GCC 3.3 release criteria

[Janis Johnson]

On Sun, Mar 09, 2003 at 09:02:40PM -0500, Kaveh R. Ghazi wrote:
>  > From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
>  > 
>  > > > From: Matthias Klose <doko at cs dot tu-berlin dot de>
>  > > > 
>  > > > Kaveh R. Ghazi writes:
>  > > > >  > From: Matthias Klose <doko at cs dot tu-berlin dot de>
>  > > > >  > 
>  > > > >  > yes, then I will "test" it on Debian unstable as well.
>  > > > > 
>  > > > > Great, thanks.  Though be aware that being the "tester" will mean
>  > > > > Debian specific bugs will be pointed your way, and the responsibility
>  > > > > to fix them prior to the release being made is yours not that of the
>  > > > > Release Manager.
>  > > > 
>  > > > Well, then please leave this field blank. I cannot commit on this.
>  > > 
>  > > Sorry to hear that.  Is there anyone else who will commit to ensuring
>  > > that GCC 3.3 works on some version of x86 Debian?
>  > 
>  > I think that your asking a bit too much of the testors in trying to
>  > make them resposible for fixing "Debian" specific bugs.  It's a valuable
>  > contribution just to setup and run the debian build using 3.3.
>  > Dave
> 
> I never said Matthias shouldn't do any tests.  Far from it!
> I welcome that contribution.
> 
> But that doesn't preclude me from calling for someone who *will* step
> forward and commit to ensuring x86 debian works.  The worst that can
> happen is that no one accepts.
> 
> So I repeat, is there anyone willing to do this?

There ought to be separate categories for testers (people who are doing
regular bootstraps, regression test runs, and running application tests)
and fixers.  Even if there's not a fixer, it's useful to know that
someone is testing the platform and reporting problems.

Janis

Re: GCC 3.3 release criteria

[Kaveh R. Ghazi]

 > From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
 > 
 > > > From: Matthias Klose <doko at cs dot tu-berlin dot de>
 > > > 
 > > > Kaveh R. Ghazi writes:
 > > > >  > From: Matthias Klose <doko at cs dot tu-berlin dot de>
 > > > >  > 
 > > > >  > yes, then I will "test" it on Debian unstable as well.
 > > > > 
 > > > > Great, thanks.  Though be aware that being the "tester" will mean
 > > > > Debian specific bugs will be pointed your way, and the responsibility
 > > > > to fix them prior to the release being made is yours not that of the
 > > > > Release Manager.
 > > > 
 > > > Well, then please leave this field blank. I cannot commit on this.
 > > 
 > > Sorry to hear that.  Is there anyone else who will commit to ensuring
 > > that GCC 3.3 works on some version of x86 Debian?
 > 
 > I think that your asking a bit too much of the testors in trying to
 > make them resposible for fixing "Debian" specific bugs.  It's a valuable
 > contribution just to setup and run the debian build using 3.3.
 > Dave

I never said Matthias shouldn't do any tests.  Far from it!
I welcome that contribution.

But that doesn't preclude me from calling for someone who *will* step
forward and commit to ensuring x86 debian works.  The worst that can
happen is that no one accepts.

So I repeat, is there anyone willing to do this?

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

Re: GCC 3.3 release criteria

[John David Anglin]

Ghazi,

> > From: Matthias Klose <doko at cs dot tu-berlin dot de>
> > 
> > Kaveh R. Ghazi writes:
> > >  > From: Matthias Klose <doko at cs dot tu-berlin dot de>
> > >  > 
> > >  > yes, then I will "test" it on Debian unstable as well.
> > > 
> > > Great, thanks.  Though be aware that being the "tester" will mean
> > > Debian specific bugs will be pointed your way, and the responsibility
> > > to fix them prior to the release being made is yours not that of the
> > > Release Manager.
> > 
> > Well, then please leave this field blank. I cannot commit on this.
> 
> Sorry to hear that.  Is there anyone else who will commit to ensuring
> that GCC 3.3 works on some version of x86 Debian?

I think that your asking a bit too much of the testors in trying to
make them resposible for fixing "Debian" specific bugs.  It's a valuable
contribution just to setup and run the debian build using 3.3.

We are trying to do a debian build on parisc-linux.  The main hicup
so far relates to the switch to dwarf2 EH as the default exception
handling in 3.3.  Because libstdc++ and libgcc_s are still at the same
versioning as 3.2, debian can't switch to dwarf2 until the versioning
changes, or they do a complete new release.  This is a PA specific
issue but possibly other ports have other reasons to bump the versions
of libstdc++ and libgcc_s.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.3 release criteria

[Kaveh R. Ghazi]

 > From: Matthias Klose <doko@cs.tu-berlin.de>
 > 
 > Kaveh R. Ghazi writes:
 > >  > From: Matthias Klose <doko@cs.tu-berlin.de>
 > >  > 
 > >  > yes, then I will "test" it on Debian unstable as well.
 > > 
 > > Great, thanks.  Though be aware that being the "tester" will mean
 > > Debian specific bugs will be pointed your way, and the responsibility
 > > to fix them prior to the release being made is yours not that of the
 > > Release Manager.
 > 
 > Well, then please leave this field blank. I cannot commit on this.

Sorry to hear that.  Is there anyone else who will commit to ensuring
that GCC 3.3 works on some version of x86 Debian?

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

Re: GCC 3.3 release criteria

[Matthias Klose]

[sorry for the late reply, this mail went into some obscure folder]
Kaveh R. Ghazi writes:
>  > From: Matthias Klose <doko@cs.tu-berlin.de>
>  > 
>  > Kaveh R. Ghazi writes:
>  > > Thanks Matthias, but seeing your patch two things occur to me:
>  > > 
>  > > One is we don't have a "tester" for x86 Debian (of any version), would
>  > > you like to volunteer to be it?
>  > 
>  > yes, then I will "test" it on Debian unstable as well.
> 
> Great, thanks.  Though be aware that being the "tester" will mean
> Debian specific bugs will be pointed your way, and the responsibility
> to fix them prior to the release being made is yours not that of the
> Release Manager.

Well, then please leave this field blank. I cannot commit on this.

>  > We apply some patches to the packages, for which descriptions are
>  > included into the test reports. These patches include
> 
> For the purposes of evaluating release criteria, it's important to
> test and post results for a "clean" source tree.  It does no good to
> say GCC 3.3 works with N extra patches when deciding whether 3.3 alone
> is releasable with regards to Debian.  Don't you agree?

I agree. I'll check it independantly of the Debian builds. The Debian
builds are already marked with "(Debian prerelease)" instead of
"(prerelease)" in the version string.

	Matthias

Re: GCC 3.3 release criteria

[Ben Collins]

> Ok, I'm proposing this change.  Is this correct in your eyes?
> 
> (Heh, notice the triplet correction I discovered!)

Looks good.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: GCC 3.3 release criteria

[Kaveh R. Ghazi]

 > From: Matthias Klose <doko@cs.tu-berlin.de>
 > 
 > Kaveh R. Ghazi writes:
 > > Thanks Matthias, but seeing your patch two things occur to me:
 > > 
 > > One is we don't have a "tester" for x86 Debian (of any version), would
 > > you like to volunteer to be it?
 > 
 > yes, then I will "test" it on Debian unstable as well.

Great, thanks.  Though be aware that being the "tester" will mean
Debian specific bugs will be pointed your way, and the responsibility
to fix them prior to the release being made is yours not that of the
Release Manager.


 > We apply some patches to the packages, for which descriptions are
 > included into the test reports. These patches include

For the purposes of evaluating release criteria, it's important to
test and post results for a "clean" source tree.  It does no good to
say GCC 3.3 works with N extra patches when deciding whether 3.3 alone
is releasable with regards to Debian.  Don't you agree?


Is the patch below correct in your eyes?



Index: criteria.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.3/criteria.html,v
retrieving revision 1.3
diff -u -p -r1.3 criteria.html
--- criteria.html	4 Mar 2003 05:41:22 -0000	1.3
+++ criteria.html	4 Mar 2003 14:41:59 -0000
@@ -77,7 +77,8 @@ possible, the release will support other
                       <td>hppa2.0w-hp-hpux11.00</td>
     <td><a href="mailto:dave@hiauly1.hia.nrc.ca">John David Anglin</a></td>
 </tr>
-<tr><td>Intel x86</td><td>Debian GNU/Linux 2.2</td><td>i386-pc-linux-gnu</td><td>&nbsp;</td></tr>
+<tr><td>Intel x86</td><td>Debian GNU/Linux 3.0</td><td>i386-pc-linux-gnu</td>
+<td><a href="mailto:doko@cs.tu-berlin.de">Matthias Klose</a></td></tr>
 <tr><td>Intel x86</td><td>RedHat Linux 6.2</td>    <td>i686-pc-linux-gnu</td><td>&nbsp;</td></tr>
 <tr><td>Intel x86</td><td>FreeBSD 4.5</td>
                       <td>i386-unknown-freebsd4.5</td>

Re: GCC 3.3 release criteria

[Kaveh R. Ghazi]

 > From: Ben Collins <bcollins@debian.org>
 > 
 > > Thanks for responding, however that was a little vague.  For the
 > > purposes of these release criteria, what I'd like to clarify is:
 > > 
 > > 1.  Will you specifically commit to testing gcc-3.3 on Debian?
 > 
 > Yes.

Great!


 > > 2.  Will you be able to post regular testsuite results?
 > 
 > I can start doing that, yes.

Thanks, I look forward to seeing them.


 > > 3.  Which version of Debian will you be using on sparc (2.2 or 3.0) ?
 > 
 > Neither. I'll be using our development release (since that's where we
 > will release gcc-3.3 anyway), which is glibc 2.3.1 based at the moment.


Ok, I'm proposing this change.  Is this correct in your eyes?

(Heh, notice the triplet correction I discovered!)


Index: criteria.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.3/criteria.html,v
retrieving revision 1.3
diff -u -p -r1.3 criteria.html
--- criteria.html	4 Mar 2003 05:41:22 -0000	1.3
+++ criteria.html	4 Mar 2003 14:34:31 -0000
@@ -126,7 +126,7 @@ answering questions and reviewing patche
                       <td>powerpc-linux-gnu</td>
     <td><a href="mailto:Franz.Sirl-kernel@lauterbach.com">Franz Sirl</a></td>
 </tr>
-<tr><td>SPARC</td>    <td>Debian GNU/Linux 2.2</td><td>sparc-sun-linux-gnu</td>
+<tr><td>SPARC</td>    <td>Debian GNU/Linux 2.3.1</td><td>sparc-unknown-linux-gnu</td>
     <td><a href="mailto:bcollins@debian.org">Ben Collins</a></td></tr>
 <tr><td>ARM</td>      <td>GNU/Linux</td>           <td>armv4l-unknown-linux-gnu</td><td>&nbsp;</td></tr>
 <tr><td>Intel x86</td><td>Cygwin</td>              <td>i686-pc-cygwin</td><td>&nbsp;</td></tr>

Re: GCC 3.3 release criteria

[Matthias Klose]

Kaveh R. Ghazi writes:
>  > From: Matthias Klose <doko@cs.tu-berlin.de>
>  > 
>  > Kaveh R. Ghazi writes:
>  > >  > From: Matthias Klose <doko@cs.tu-berlin.de>
>  > >  > 
>  > >  > The Debian GNU/Linux platform should be changed to 3.0 (released last
>  > >  > summer). This is still glibc-2.2.5 based. Is one of the other distros
>  > >  > mentioned glibc-2.3.1 based?
>  > >  > 	Matthias
>  > > 
>  > > The file is now checked in, if you would submit your suggested change
>  > > in patch form, that would be better.
> 
> 
> Thanks Matthias, but seeing your patch two things occur to me:
> 
> One is we don't have a "tester" for x86 Debian (of any version), would
> you like to volunteer to be it?

yes, then I will "test" it on Debian unstable as well. Testresults are
already sent for each sucessful build to gcc-testresults. This
includes all current linux architectures (alpha, arm,  hppa, i386,
ia64, m68k, mips, mipsel, powerpc, s390, sparc) and netbsd-i386.
No testresults are sent for the Hurd due to a missing/non functional
ulimit implementation.

We apply some patches to the packages, for which descriptions are
included into the test reports. These patches include

- "installation" patches (build versioned info files, find headers
  for gc enabled objc library, etc)

- patches sent to gcc-patches.

- In libf2c libjava/libltdl libobjc libstdc++-v3 zlib, autoreconf --force
  is run to support mips and mipsel.

Some patches are submitted, but not yet reviewed.

For further testing the applications mentioned on the page I'll ask
the Debian package maintainers (if these packages are packaged for
Debian). Are the versions of these packages still valid?

> Second, the "tester" for sparc Debian is Ben Collins and it's not
> clear if he plans to use 3.0 or if he remains committed to testing at
> all.  I quick search of the testsuite results list shows no postings
> by him, but I think we should check before proceeding.  (I've CC:ed
> him on this message, hopefully he'll respond.)

There is another "GNU/Linux" target (armv4l-unknown-linux-gnu)
mentioned as secondary platform. Maybe Phil Blundell can test this
one? At least the test results are already sent for arm-linux as well
(although the bootstrap is currently broken).

	Matthias

Re: GCC 3.3 release criteria

[Ben Collins]

> Thanks for responding, however that was a little vague.  For the
> purposes of these release criteria, what I'd like to clarify is:
> 
> 1.  Will you specifically commit to testing gcc-3.3 on Debian?

Yes.

> 2.  Will you be able to post regular testsuite results?

I can start doing that, yes.

> 3.  Which version of Debian will you be using on sparc (2.2 or 3.0) ?

Neither. I'll be using our development release (since that's where we
will release gcc-3.3 anyway), which is glibc 2.3.1 based at the moment.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: GCC 3.3 release criteria

[Kaveh R. Ghazi]

 > From: Ben Collins <bcollins@debian.org>
 > 
 > > Thanks Matthias, but seeing your patch two things occur to me:
 > > 
 > > One is we don't have a "tester" for x86 Debian (of any version), would
 > > you like to volunteer to be it?
 > > 
 > > Second, the "tester" for sparc Debian is Ben Collins and it's not
 > > clear if he plans to use 3.0 or if he remains committed to testing at
 > > all.  I quick search of the testsuite results list shows no postings
 > > by him, but I think we should check before proceeding.  (I've CC:ed
 > > him on this message, hopefully he'll respond.)
 > > 
 > > If no one steps forward to actually test sparc Debian, I suggest we
 > > recruit a "tester" and/or find another linux-gnu target since there
 > > are many sparc postings from others who are actively testing.
 > 
 > I am current testing gcc-3.x. I've not discovered many problems that
 > weren't already discovered (I'm admittedly a little slower than other
 > testers).

Thanks for responding, however that was a little vague.  For the
purposes of these release criteria, what I'd like to clarify is:

1.  Will you specifically commit to testing gcc-3.3 on Debian?
2.  Will you be able to post regular testsuite results?
3.  Which version of Debian will you be using on sparc (2.2 or 3.0) ?

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

Re: GCC 3.3 release criteria

[Ben Collins]

On Sat, Mar 01, 2003 at 10:55:54AM -0500, Kaveh R. Ghazi wrote:
>  > From: Matthias Klose <doko@cs.tu-berlin.de>
>  > 
>  > Kaveh R. Ghazi writes:
>  > >  > From: Matthias Klose <doko@cs.tu-berlin.de>
>  > >  > 
>  > >  > The Debian GNU/Linux platform should be changed to 3.0 (released last
>  > >  > summer). This is still glibc-2.2.5 based. Is one of the other distros
>  > >  > mentioned glibc-2.3.1 based?
>  > >  > 	Matthias
>  > > 
>  > > The file is now checked in, if you would submit your suggested change
>  > > in patch form, that would be better.
> 
> 
> Thanks Matthias, but seeing your patch two things occur to me:
> 
> One is we don't have a "tester" for x86 Debian (of any version), would
> you like to volunteer to be it?
> 
> Second, the "tester" for sparc Debian is Ben Collins and it's not
> clear if he plans to use 3.0 or if he remains committed to testing at
> all.  I quick search of the testsuite results list shows no postings
> by him, but I think we should check before proceeding.  (I've CC:ed
> him on this message, hopefully he'll respond.)
> 
> If no one steps forward to actually test sparc Debian, I suggest we
> recruit a "tester" and/or find another linux-gnu target since there
> are many sparc postings from others who are actively testing.

I am current testing gcc-3.x. I've not discovered many problems that
weren't already discovered (I'm admittedly a little slower than other
testers).

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: GCC 3.3 release criteria

[Kaveh R. Ghazi]

 > From: Matthias Klose <doko@cs.tu-berlin.de>
 > 
 > Kaveh R. Ghazi writes:
 > >  > From: Matthias Klose <doko@cs.tu-berlin.de>
 > >  > 
 > >  > The Debian GNU/Linux platform should be changed to 3.0 (released last
 > >  > summer). This is still glibc-2.2.5 based. Is one of the other distros
 > >  > mentioned glibc-2.3.1 based?
 > >  > 	Matthias
 > > 
 > > The file is now checked in, if you would submit your suggested change
 > > in patch form, that would be better.


Thanks Matthias, but seeing your patch two things occur to me:

One is we don't have a "tester" for x86 Debian (of any version), would
you like to volunteer to be it?

Second, the "tester" for sparc Debian is Ben Collins and it's not
clear if he plans to use 3.0 or if he remains committed to testing at
all.  I quick search of the testsuite results list shows no postings
by him, but I think we should check before proceeding.  (I've CC:ed
him on this message, hopefully he'll respond.)

If no one steps forward to actually test sparc Debian, I suggest we
recruit a "tester" and/or find another linux-gnu target since there
are many sparc postings from others who are actively testing.

		--Kaveh



 > --- criteria.html~	Tue Feb 25 18:03:51 2003
 > +++ criteria.html	Tue Feb 25 18:05:28 2003
 > @@ -127,7 +128,7 @@
 >                        <td>hppa2.0w-hp-hpux11.00</td>
 >      <td><a href="mailto:dave@hiauly1.hia.nrc.ca">John David Anglin</a></td>
 >  </tr>
 > -<tr><td>Intel x86</td><td>Debian GNU/Linux 2.2</td><td>i386-pc-linux-gnu</td><td>&nbsp;</td></tr>
 > +<tr><td>Intel x86</td><td>Debian GNU/Linux 3.0</td><td>i386-pc-linux-gnu</td><td>&nbsp;</td></tr>
 >  <tr><td>Intel x86</td><td>RedHat Linux 6.2</td>    <td>i686-pc-linux-gnu</td><td>&nbsp;</td></tr>
 >  <tr><td>Intel x86</td><td>FreeBSD 4.5</td>
 >                        <td>i386-unknown-freebsd4.5</td>
 > @@ -176,7 +177,7 @@
 >                        <td>powerpc-linux-gnu</td>
 >      <td><a href="mailto:Franz.Sirl-kernel@lauterbach.com">Franz Sirl</a></td>
 >  </tr>
 > -<tr><td>SPARC</td>    <td>Debian GNU/Linux 2.2</td><td>sparc-sun-linux-gnu</td>
 > +<tr><td>SPARC</td>    <td>Debian GNU/Linux 3.0</td><td>sparc-sun-linux-gnu</td>
 >      <td><a href="mailto:bcollins@debian.org">Ben Collins</a></td></tr>
 >  <tr><td>ARM</td>      <td>GNU/Linux</td>           <td>armv4l-unknown-linux-gnu</td><td>&nbsp;</td></tr>
 >  <tr><td>Intel x86</td><td>Cygwin</td>              <td>i686-pc-cygwin</td><td>&nbsp;</td></tr>

Re: GCC 3.3 release criteria

[Robert Dewar]

> If people in C land are complaining that C doesn't inline enough, and 
> have not complained that it does it too much, then obviously this is a 
> compiler bug and C should inline more.  There isn't a reason that C and 
> C++ have to use the same exact heuristics.


I also think it is reasonable to have different heuristics for the cases where the
programmer demands inlining and where the compiler on its own thinks it might be
a good idea (that's what we do in GNAT, where nevertheless we often find that -O3
deoptimizes, since the programmer has done a pretty good job of figuring out what
to inline).

P.S. I knwo my mailer is still not threading, I am working on fixing this.

Re: GCC 3.3 release criteria

[Mike Stump]

On Wednesday, February 26, 2003, at 06:57 AM, Robert Dewar wrote:
>> 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.
>
> Indeed that is a common style, and I would say that if the compiler 
> does
> not inline in such a case, then even if the inline keyword is advisory,
> this would seem to be a bug!

If people in C land are complaining that C doesn't inline enough, and 
have not complained that it does it too much, then obviously this is a 
compiler bug and C should inline more.  There isn't a reason that C and 
C++ have to use the same exact heuristics.

What I do know, is that it did inline too much in C++ when confronted 
with default inline template code, and that we should not undo this for 
C++.

Can we just bump up the heuristic for C by, say 10x and see how people 
like it.  If they don't complain, and the people that used to complain 
about C stop, then that _is_ a better choice.  If 10x is too small, how 
about 100x?

Re: GCC 3.3 release criteria

[Robert Dewar]

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

Indeed that is a common style, and I would say that if the compiler does
not inline in such a case, then even if the inline keyword is advisory,
this would seem to be a bug!

Re: GCC 3.3 release criteria

[Robert Dewar]

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

This seems a reasonable expectation for sure (that if you ask for a functoin
to be inlined, and the function doesn't use constructs that are unsuitable
for inlining, and you are using -O, then calls should be inlined, assuming
this will in fact generate faster code, as is the case on most processors.
Note also that inlining helps avoid cache flushing anomolies.

Re: GCC 3.3 release criteria

[Kaveh R. Ghazi]

 > From: Janis Johnson <janis187@us.ibm.com>
 > 
 > On Tue, Feb 25, 2003 at 11:24:19AM -0500, Kaveh R. Ghazi wrote:
 > > Would one of our doc experts help suggest a place to link to this
 > > file?  Currently nothing does, and the older GCC directory versions
 > > were not helpful since I couldn't find anything that links to those
 > > criteria either.
 > 
 > The following has been added as wwwdocs/htdocs/gcc-3.3/index.html,
 > it's now linked from the home page.
 > Janis

Thanks!

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

Re: GCC 3.3 release criteria

[Janis Johnson]

On Tue, Feb 25, 2003 at 11:24:19AM -0500, Kaveh R. Ghazi wrote:
> Would one of our doc experts help suggest a place to link to this
> file?  Currently nothing does, and the older GCC directory versions
> were not helpful since I couldn't find anything that links to those
> criteria either.

The following has been added as wwwdocs/htdocs/gcc-3.3/index.html,
it's now linked from the home page.

Janis

--- /dev/null	Tue May 23 09:27:54 2000
+++ index.html	Tue Feb 25 10:11:33 2003
@@ -0,0 +1,31 @@
+<html>
+
+<head>
+<title>GCC 3.3</title>
+</head>
+
+<body>
+
+<h1>GCC 3.3</h1>
+
+<p>GCC 3.3 is the active release branch of GCC, currently in
+<a href="../develop.html#stage3">stage 3</a> of development.  A set
+of <a href="criteria.html">release criteria</a> define when this version
+will be ready for release.</p>
+
+<p>GCC 3.3 will include numerous <a href="changes.html">new features,
+improvements, bug fixes, and other changes</a>, thanks to an
+<a href="http://gcc.gnu.org/onlinedocs/gcc/Contributors.html">amazing
+group of volunteers</a>.</p>
+
+<p><a href="gcj-status.html">GCJ 3.3 status</a> is tracked for a
+variety of targets and test packages.</p>
+
+<p>GCC, the GNU Compiler Collection, is part of the
+<a href="http://www.gnu.org/">GNU project</a>.
+For additional information about GCC please refer to the
+<a href="../index.html">GCC project web site</a> or contact the
+<a href="mailto:gcc@gcc.gnu.org">GCC development mailing list</a>.</p>
+
+</body>
+</html>

Re: GCC 3.3 release criteria

[Janis Johnson]

On Tue, Feb 25, 2003 at 11:24:19AM -0500, Kaveh R. Ghazi wrote:
>  > From: Mark Mitchell <mark@codesourcery.com>
>  > 
>  > On Sun, 2003-02-23 at 15:54, Kaveh R. Ghazi wrote:
>  > > I think it's well past time we had written release criteria for GCC
>  > > 3.3.  I propose starting with the 3.1 criteria and working from there.
>  > > I've copied criteria.html from the gcc-3.1 to the gcc-3.3 directory
>  > > and changed "3.1" -> "3.3" everywhere.  I also removed a paragraph
>  > > relating to the C++ ABI change in 3.2.  Then we can make changes from
>  > > there in patch form.  The entire file is included below.
>  > 
>  > Yes, please do add this.  I think this section:
>  > 
>  >   In particular, the current regression testsuite
>  >   will be run using GCC 3.0.4 and GCC 2.95.3 on each of the supported
>  >   platforms; those results can then be compared with the output from a
>  >   release candidate.
>  > 
>  > is a little out of date; we should probably use GCC 3.2.x there instead.
> 
> Thanks done.
> 
> Would one of our doc experts help suggest a place to link to this
> file?  Currently nothing does, and the older GCC directory versions
> were not helpful since I couldn't find anything that links to those
> criteria either.

I'll put together a gcc-3.3/index.html file with links to the other
files in that directory that ought to be visible now.

Janis

Re: GCC 3.3 release criteria

[Matthias Klose]

Kaveh R. Ghazi writes:
>  > From: Matthias Klose <doko@cs.tu-berlin.de>
>  > 
>  > The Debian GNU/Linux platform should be changed to 3.0 (released last
>  > summer). This is still glibc-2.2.5 based. Is one of the other distros
>  > mentioned glibc-2.3.1 based?
>  > 	Matthias
> 
> The file is now checked in, if you would submit your suggested change
> in patch form, that would be better.

--- criteria.html~	Tue Feb 25 18:03:51 2003
+++ criteria.html	Tue Feb 25 18:05:28 2003
@@ -127,7 +128,7 @@
                       <td>hppa2.0w-hp-hpux11.00</td>
     <td><a href="mailto:dave@hiauly1.hia.nrc.ca">John David Anglin</a></td>
 </tr>
-<tr><td>Intel x86</td><td>Debian GNU/Linux 2.2</td><td>i386-pc-linux-gnu</td><td>&nbsp;</td></tr>
+<tr><td>Intel x86</td><td>Debian GNU/Linux 3.0</td><td>i386-pc-linux-gnu</td><td>&nbsp;</td></tr>
 <tr><td>Intel x86</td><td>RedHat Linux 6.2</td>    <td>i686-pc-linux-gnu</td><td>&nbsp;</td></tr>
 <tr><td>Intel x86</td><td>FreeBSD 4.5</td>
                       <td>i386-unknown-freebsd4.5</td>
@@ -176,7 +177,7 @@
                       <td>powerpc-linux-gnu</td>
     <td><a href="mailto:Franz.Sirl-kernel@lauterbach.com">Franz Sirl</a></td>
 </tr>
-<tr><td>SPARC</td>    <td>Debian GNU/Linux 2.2</td><td>sparc-sun-linux-gnu</td>
+<tr><td>SPARC</td>    <td>Debian GNU/Linux 3.0</td><td>sparc-sun-linux-gnu</td>
     <td><a href="mailto:bcollins@debian.org">Ben Collins</a></td></tr>
 <tr><td>ARM</td>      <td>GNU/Linux</td>           <td>armv4l-unknown-linux-gnu</td><td>&nbsp;</td></tr>
 <tr><td>Intel x86</td><td>Cygwin</td>              <td>i686-pc-cygwin</td><td>&nbsp;</td></tr>

Re: GCC 3.3 release criteria

[Janis Johnson]

On Mon, Feb 24, 2003 at 06:41:03PM -0800, Mark Mitchell wrote:
> > > Can we add Samba to the list?  It is quite widely used, and 3.2.2
> > > currently has a Samba regression at -O2 on Sparc that has
> > > caused some public wailing and gnashing of teeth.
> 
> I think we have enough applications on the list.  It would be great to
> test every application imaginable -- but we simply do not have the
> resources to do so.

It's appropriate for the list of applications used as release criteria
to be short, but the list in testing/index.html is useful for people
interested in pounding on GCC with a variety of input and we shouldn't
need to limit it.

Janis

Re: GCC 3.3 release criteria

[Kaveh R. Ghazi]

 > From: Mark Mitchell <mark@codesourcery.com>
 > 
 > On Sun, 2003-02-23 at 15:54, Kaveh R. Ghazi wrote:
 > > I think it's well past time we had written release criteria for GCC
 > > 3.3.  I propose starting with the 3.1 criteria and working from there.
 > > I've copied criteria.html from the gcc-3.1 to the gcc-3.3 directory
 > > and changed "3.1" -> "3.3" everywhere.  I also removed a paragraph
 > > relating to the C++ ABI change in 3.2.  Then we can make changes from
 > > there in patch form.  The entire file is included below.
 > 
 > Yes, please do add this.  I think this section:
 > 
 >   In particular, the current regression testsuite
 >   will be run using GCC 3.0.4 and GCC 2.95.3 on each of the supported
 >   platforms; those results can then be compared with the output from a
 >   release candidate.
 > 
 > is a little out of date; we should probably use GCC 3.2.x there instead.

Thanks done.

Would one of our doc experts help suggest a place to link to this
file?  Currently nothing does, and the older GCC directory versions
were not helpful since I couldn't find anything that links to those
criteria either.

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

Re: GCC 3.3 release criteria

[Kaveh R. Ghazi]

 > From: Matthias Klose <doko@cs.tu-berlin.de>
 > 
 > The Debian GNU/Linux platform should be changed to 3.0 (released last
 > summer). This is still glibc-2.2.5 based. Is one of the other distros
 > mentioned glibc-2.3.1 based?
 > 	Matthias

The file is now checked in, if you would submit your suggested change
in patch form, that would be better.

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

Re: GCC 3.3 release criteria

[Paolo Bonzini]

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

I agree.  Though for more control I'd like very much:

- __asm__() or __attribute__(always_register) for putting a variable into 
whatever register the compiler cares, but *in a register*

- __asm__(regclass) which can be very handy for example for reserving a branch 
register on the IA64.

-- 
|_  _  _ __
|_)(_)| ) ;'_.

Re: GCC 3.3 release criteria

[Robert Dewar]

> Ideally, there should be switches that enables the compiler to report
> cases where it thinks it knows better than the programmer (no, the
> current behaviour of -Winline does not cover that case).

In GNAT, there is Inline, which is just advice as per the standard, and then
we added Inline_Always which must be obeyed. We also have an optional warning
if Inline is not obeyed.

Here is an example from the GNAT world where Inline_Always is crucial. In our
high integrity product that is to be certified following FAA certification
standards, we have certain simple functions that are written as separate
functions but generate no code at all (e.g. To_Address which converts between
two forms of addresses that in fact have the same representation). If this
is inlined, then there is no separate object file to be taken into account
during certification. So the issue here is reducing certification burden
and not efficiency. This is a good example of a case where the compiler
cannot understand that it is critical that this directive be obeyed.
An example where we absolutely do NOT want inlining is where the debugger
must intercept a call.

Re: GCC 3.3 release criteria

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| >    I think that somtimes 'high level' people don't quite understand the
| > issues involved when you have timing constraints on sections of code.
| 
| Actually timing constraints is a weak argument. What about a case in which the
| compiler sees the "INLINE" but determines that it is more efficient (time wise)
| NOT to inline.

I believe that the argument of the poster was that the compiler is always
programmed according the implementor's logic which does not always
match the programmer's.  

Not just because the compiler *may* in _certain cases_ know better
than the programmers means that the compiler should always have the
final word.  Making things so just create gaps and misunderstandings
bewteen "programmers in the trenches" and  implementors. 

Ideally, there should be switches that enables the compiler to report
cases where it thinks it knows better than the programmer (no, the
current behaviour of -Winline does not cover that case).

-- Gaby

Re: GCC 3.3 release criteria

[Robert Dewar]

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

Actually timing constraints is a weak argument. What about a case in which the
compiler sees the "INLINE" but determines that it is more efficient (time wise)
NOT to inline. If timing constraints are the major motivator then "inline" should
mean "make calling this fast, speed is more important than space, go ahead and
inline if it will help".

Re: GCC 3.3 release criteria

[Eric Botcazou]

> That said, please make sure PR8726 has high priority so that we know to
> look at it!

I have a patch for PR 8726 sitting on my hard disk. I'll test it on various
Sparc machines I now have access to, but not before the next week.

- Eric

Re: GCC 3.3 release criteria

[Matthias Klose]

Mark Mitchell writes:
> On Sun, 2003-02-23 at 15:54, Kaveh R. Ghazi wrote:
> > I think it's well past time we had written release criteria for GCC
> > 3.3.  I propose starting with the 3.1 criteria and working from there.
> > I've copied criteria.html from the gcc-3.1 to the gcc-3.3 directory
> > and changed "3.1" -> "3.3" everywhere.  I also removed a paragraph
> > relating to the C++ ABI change in 3.2.  Then we can make changes from
> > there in patch form.  The entire file is included below.
> 
> Yes, please do add this.  I think this section:
> 
>   In particular, the current regression testsuite
>   will be run using GCC 3.0.4 and GCC 2.95.3 on each of the supported
>   platforms; those results can then be compared with the output from a
>   release candidate.
> 
> is a little out of date; we should probably use GCC 3.2.x there instead.

The Debian GNU/Linux platform should be changed to 3.0 (released last
summer). This is still glibc-2.2.5 based. Is one of the other distros
mentioned glibc-2.3.1 based?

	Matthias

Re: GCC 3.3 release criteria

[Mark Mitchell]

> > Can we add Samba to the list?  It is quite widely used, and 3.2.2
> > currently has a Samba regression at -O2 on Sparc that has
> > caused some public wailing and gnashing of teeth.

I think we have enough applications on the list.  It would be great to
test every application imaginable -- but we simply do not have the
resources to do so.

That said, please make sure PR8726 has high priority so that we know to
look at it!

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3 release criteria

[Mark Mitchell]

On Sun, 2003-02-23 at 15:54, Kaveh R. Ghazi wrote:
> I think it's well past time we had written release criteria for GCC
> 3.3.  I propose starting with the 3.1 criteria and working from there.
> I've copied criteria.html from the gcc-3.1 to the gcc-3.3 directory
> and changed "3.1" -> "3.3" everywhere.  I also removed a paragraph
> relating to the C++ ABI change in 3.2.  Then we can make changes from
> there in patch form.  The entire file is included below.

Yes, please do add this.  I think this section:

  In particular, the current regression testsuite
  will be run using GCC 3.0.4 and GCC 2.95.3 on each of the supported
  platforms; those results can then be compared with the output from a
  release candidate.

is a little out of date; we should probably use GCC 3.2.x there instead.

Thanks!!

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3 release criteria

[Kaveh R. Ghazi]

 > From: Jason R Thorpe <thorpej@wasabisystems.com>
 > 
 > On Sun, Feb 23, 2003 at 06:54:52PM -0500, Kaveh R. Ghazi wrote:
 > 
 > [ ... snip ... ]
 > 
 > I'd like to have NetBSD added to the secondary platform list.  Within the
 > last year, NetBSD has become much more visible in GCC development activity
 > (though I admit that I haven't had a lot of time for GCC in the last couple
 > of months).  Attempts to build the NetBSD source tree (kernel and userland)
 > have also turned up regressions in GCC.
 > 
 > In particular, I'd like for:
 > 
 > 	alpha-unknown-netbsd1.6
 > 	arm-unknown-netbsdelf1.6
 > 	i386-unknown-netbsdelf1.6
 > 	mipseb-unknown-netbsd1.6
 > 	sparc-unknown-netbsd1.6
 > 	sparc64-unknown-netbsd1.6
 > 
 > to be considered.  In addition to myself, I can probably scare up (through
 > bribery or other forms of friendly coercion :-) a couple of other volunteers
 > to help out with this (Hi Krister, Matt, and Richard E :-)

We're of course supportive of "free" systems that use GCC as their
system compiler and we appreciate bug reports (and fixes) generated as
a result of your testing.  We'd need commitments from individuals for
testing and fixing problems to consider this, i.e. we can't just add
new systems and place the burden on the RM to support them.  Running
automated regression testers and posting the results certainly helps
your case.  (Hint hint.)

But six targets seems like a lot.  Which one is your top concern?
(Consider chosing something other than x86 cause we have a bunch of
those already.)

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

Re: GCC 3.3 release criteria

[Jason R Thorpe]

On Sun, Feb 23, 2003 at 06:54:52PM -0500, Kaveh R. Ghazi wrote:

[ ... snip ... ]

I'd like to have NetBSD added to the secondary platform list.  Within the
last year, NetBSD has become much more visible in GCC development activity
(though I admit that I haven't had a lot of time for GCC in the last couple
of months).  Attempts to build the NetBSD source tree (kernel and userland)
have also turned up regressions in GCC.

In particular, I'd like for:

	alpha-unknown-netbsd1.6
	arm-unknown-netbsdelf1.6
	i386-unknown-netbsdelf1.6
	mipseb-unknown-netbsd1.6
	sparc-unknown-netbsd1.6
	sparc64-unknown-netbsd1.6

to be considered.  In addition to myself, I can probably scare up (through
bribery or other forms of friendly coercion :-) a couple of other volunteers
to help out with this (Hi Krister, Matt, and Richard E :-)

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: GCC 3.3 release criteria

[Janis Johnson]

On Mon, Feb 24, 2003 at 12:04:58PM -0800, Dan Kegel wrote:
> Kaveh R. Ghazi wrote:
> > <h3>Applications</h3>
> > 
> > <p>It is important that the compiler is verified on real-world
> > applications.  The following applications represent a mix of low-level
> > and high-level code, of numerical and logical programs, and of
> > different programming languages.</p>
> > 
> > <tr><td><a href="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</a></td>
> >     <td>C++</td>
> >     <td>5.2</td>
> >     <td><a href="http://deuce.doc.wustl.edu/Download.html">
> >         ACE (download)</a></td>
> >     <td>&nbsp;</td>
> > </tr>
> ...
> 
> Can we add Samba to the list?  It is quite widely used, and 3.2.2
> currently has a Samba regression at -O2 on Sparc that has
> caused some public wailing and gnashing of teeth.  See bug 8726
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8726
> 
> If you agree, here's HTML that might do:
> 
> <tr><td><a href="http://www.samba.org">Samba</a></td>
>      <td>C</td>
>      <td>2.2.7a</td>
>      <td><a href="http://us2.samba.org/samba/download.html">Samba (download)</a></td>
>      <td>&nbsp;</td>
> </tr>

The release manager decides which applications to use for release
criteria.

In the meantime, though, we could add this to the list of applications
that are recommended for use in testing GCC; see the list at
http://gcc.gnu.org/testing/.  Everything in that list has a build and
test guide available that explains how to configure, build, and test
the application.  Those things might seem simple to anyone who's
already done it at least once, but these guides let other people get
set up very quickly.  If you'd like help setting up a build and test
guide for Samba, let me know.

Janis

Re: GCC 3.3 release criteria

[Dan Kegel]

Kaveh R. Ghazi wrote:
> <h3>Applications</h3>
> 
> <p>It is important that the compiler is verified on real-world
> applications.  The following applications represent a mix of low-level
> and high-level code, of numerical and logical programs, and of
> different programming languages.</p>
> 
> <tr><td><a href="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</a></td>
>     <td>C++</td>
>     <td>5.2</td>
>     <td><a href="http://deuce.doc.wustl.edu/Download.html">
>         ACE (download)</a></td>
>     <td>&nbsp;</td>
> </tr>
...

Can we add Samba to the list?  It is quite widely used, and 3.2.2
currently has a Samba regression at -O2 on Sparc that has
caused some public wailing and gnashing of teeth.  See bug 8726
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8726

If you agree, here's HTML that might do:

<tr><td><a href="http://www.samba.org">Samba</a></td>
     <td>C</td>
     <td>2.2.7a</td>
     <td><a href="http://us2.samba.org/samba/download.html">Samba (download)</a></td>
     <td>&nbsp;</td>
</tr>

Thanks,
Dan
(not subscribed)

GCC 3.3 release criteria

[Kaveh R. Ghazi]

I think it's well past time we had written release criteria for GCC
3.3.  I propose starting with the 3.1 criteria and working from there.
I've copied criteria.html from the gcc-3.1 to the gcc-3.3 directory
and changed "3.1" -> "3.3" everywhere.  I also removed a paragraph
relating to the C++ ABI change in 3.2.  Then we can make changes from
there in patch form.  The entire file is included below.

Ok to install?

Where should we link to it from?

		Thanks,
		--Kaveh





<html>

<head>
<title>GCC 3.3 Release Criteria</title>
</head>

<body>

<h1>GCC 3.3 Release Criteria</h1>

<p>This page provides the release criteria for GCC 3.3.  GCC 3.3 will
not be released until these criteria have been met.  This page
enumerates the release criteria and provides a rationale for some of
the choices made in determining these criteria.</p>

<p>In all cases, these criteria represent the minimum functionality
required in order to make the release.  If this level of minimum
functionality is not provided by a release candidate, then that
candidate will not become the eventual release.  However, a release
candidate that does meet these criteria may not necessarily become the
official release; there may be other unforseen issues that prevent
release.  For example, if support for the Intel Pentium II is required
by the release criteria, it is nevertheless unlikely that GCC 3.3
would be released even though it did not support the Intel
Pentium.</p>

<p>Because the development of GCC is largely dependent on volunteers,
the Steering Committee may eventually have to decide whether to make a
release, even if the criteria here are not met.  For example, if no
volunteer can be found to verify correct operation of a particular
application program on a particular system, then that criterion may be
abandoned.  However, that eventuality should be avoided if at all
possible.</p>

<!--
<h2>Functionality</h2>

<p>GCC 3.3 will contain considerable improvements in functionality
relative to previous releases of GCC.  Each of these improvements must
be completed before GCC 3.3 is released:</p>
<ul>
<li>...</li>
</ul>
-->


<h2>Bug Fixes</h2>

<p>We strive to fix all open problem reports (PRs) in our bug tracking
system that indicate a regression with respect to previous releases.</p>

<p>Such PRs are marked as high-priority items, and every GCC maintainer
with CVS and GNATS write access may set PRs indicating a regression to
high-priority.</p>


<h2>Platform Support</h2>

<p>GCC is available on a vast number of platforms.  However, it is not
possible to effectively test GCC in all possible configurations.
Therefore, a smaller number of platforms have been selected as
targets.  The targets chosen represent both the most popular operating
systems and the most popular microprocessors.  Of course, where
possible, the release will support other targets as well.</p>

<table align="center" border="1">
<caption>Primary Evaluation Platforms</caption>
<tr><th>Chip</th>     <th>OS</th>                  
                      <th>Triplet</th>
                      <th>Tester</th>
</tr>
<tr><td>Alpha</td>    <td>RedHat Linux 7.1</td>
                      <td>alpha-unknown-linux-gnu</td>
    <td><a href="mailto:rth@redhat.com">Richard Henderson</a></td>
</tr>
<tr><td>HPPA</td>     <td>HPUX 11.0</td>
                      <td>hppa2.0w-hp-hpux11.00</td>
    <td><a href="mailto:dave@hiauly1.hia.nrc.ca">John David Anglin</a></td>
</tr>
<tr><td>Intel x86</td><td>Debian GNU/Linux 2.2</td><td>i386-pc-linux-gnu</td><td>&nbsp;</td></tr>
<tr><td>Intel x86</td><td>RedHat Linux 6.2</td>    <td>i686-pc-linux-gnu</td><td>&nbsp;</td></tr>
<tr><td>Intel x86</td><td>FreeBSD 4.5</td>
                      <td>i386-unknown-freebsd4.5</td>
    <td><a href="mailto:rittle@latour.rsch.comm.mot.com">Loren James Rittle</a></td>
</tr>
<tr><td>MIPS</td>     <td>IRIX 6.5</td>            <td>mips-sgi-irix6.5</td><td>&nbsp;</td></tr>
<tr><td>PowerPC</td>  <td>AIX 4.3.3</td>
                      <td>powerpc-ibm-aix4.3.3.0</td>
    <td><a href="mailto:dje@watson.ibm.com">David Edelsohn</a></td>
</tr>
<tr><td>SPARC</td>    <td>Solaris 2.7</td>         <td>sparc-sun-solaris2.7</td><td>&nbsp;</td></tr>
</table>

<p>GCC's performance on the following platforms will not be required
to meet all the criteria mentioned in this document before GCC 3.3
ships, but the performance on these systems will be of considerable
interest, and it is likely that serious problems on these platforms
will delay the release.</p>

<p>Among the secondary evaluation platforms, we are are especially
concerned about free systems (i.e., GNU/Linux and the BSDs) where GCC
also serves as the system compiler.</p>

<p>Volunteers will be required, both to test and to fix bugs, for all
secondary platforms.  (These volunteers may be the same person, but
volunteers should be careful not to sign up for more work than they can
actually do.)  If volunteers cannot be found for these platforms, then
the secondary platforms will be dropped from this list.</p>

<p>The bug-fixing volunteer will commit to ensuring that GCC 3.3 will
at least bootstrap itself on each of these secondary platforms.  That
commitment doesn't necessarily mean fixing bugs personally; for
example, if you are a manager for a company with GCC expertise you
could be the volunteer if you'll commit to donating your employee's
efforts as necessary.  The release manager, and the GCC development
team, will make reasonable efforts to assist these volunteers by
answering questions and reviewing patches as time permits.</p>

<table align="center" border="1">
<caption>Secondary Evaluation Platforms</caption>
<tr><th>Chip</th>     <th>OS</th>
                      <th>Triplet</th>
    <th>Tester</th>
</tr>
<tr><td>PowerPC</td>  <td>GNU/Linux</td>
                      <td>powerpc-linux-gnu</td>
    <td><a href="mailto:Franz.Sirl-kernel@lauterbach.com">Franz Sirl</a></td>
</tr>
<tr><td>SPARC</td>    <td>Debian GNU/Linux 2.2</td><td>sparc-sun-linux-gnu</td>
    <td><a href="mailto:bcollins@debian.org">Ben Collins</a></td></tr>
<tr><td>ARM</td>      <td>GNU/Linux</td>           <td>armv4l-unknown-linux-gnu</td><td>&nbsp;</td></tr>
<tr><td>Intel x86</td><td>Cygwin</td>              <td>i686-pc-cygwin</td><td>&nbsp;</td></tr>
</table>

<h2>Language Support</h2>

<p>There are GCC front-ends for many different languages.  However, in
this release, only the behavior of front-ends for the following
languages will be considered part of the release criteria:</p>
<ul>
<li>C</li>
<li>C++</li>
<li>Java</li>
<li>Fortran</li>
</ul>

<p>The following languages will be supported by the release, but their
behavior will not be a primary consideration in determining whether or
not to ship a particular release candidate:</p>

<ul>
<li>Ada</li>
<li>Objective-C</li>
</ul>

<p>In particular, no application testing, code quality, or compile-time
performance testing will be required for these languages.  However,
the regression testing criteria documented below will apply to these
languages.</p>

<h2>Regression Tests</h2>

<p>The GCC testsuite contains extensive C and C++ regression tests, as
well as some Fortran, and Objective-C tests.  GCC 3.3 will not fail
any of these tests which the previous release GCC passed on any of the
supported platforms.  In particular, the current regression testsuite
will be run using GCC 3.0.4 and GCC 2.95.3 on each of the supported
platforms; those results can then be compared with the output from a
release candidate.
Because there have often been issues with generating PIC code, we will
test with <code>-fPIC</code> as well.</p>

<p>In addition, on all supported platforms, there will be no
<code>--enable-checking</code> failures when running any of the
regression test-suites.</p>

<h2>Additional Tests</h2>

<p>Ideally, strict compliance with the following criteria would be
required for all releases of GCC, however this is simply not practical
for GCC 3.3.  Still, testers are encouraged to perform these tests and
report possible problems.</p>

<h3>Applications</h3>

<p>It is important that the compiler is verified on real-world
applications.  The following applications represent a mix of low-level
and high-level code, of numerical and logical programs, and of
different programming languages.</p>

<table align="center" border="1">
<caption>Integration Tests</caption>
<tr><th>Name</th>
    <th>Language</th>
    <th>Version</th>
    <th>Source URL</th>
    <th>Build and test guide</th>
</tr>
<tr><td><a href="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</a></td>
    <td>C++</td>
    <td>5.2</td>
    <td><a href="http://deuce.doc.wustl.edu/Download.html">
        ACE (download)</a></td>
    <td>&nbsp;</td>
</tr>
<tr><td><a href="http://www.oonumerics.org/blitz/">Blitz</a></td>
    <td>C++</td>
    <td>20001213</td>
    <td><a href="http://www.oonumerics.org/blitz/download/snapshots/blitz-20001213.tar.gz">blitz-20001213.tar.gz</a></td>
    <td><a href="testing-blitz.html">build and test guide</a></td>
</tr>
<tr><td><a href="http://www.boost.org/">Boost</a></td>
    <td>C++</td>
    <td>1.22.0</td> <!-- the download link they give here isn't versioned... -->
    <td><a href="http://www.boost.org/boost_all.tar.gz">boost_all.tar.gz</a></td>
    <td><a href="testing-boost.html">build and test guide</a></td>
</tr>
<tr><td><a href="http://superbeast.ucsd.edu/~landry/FTensor/">FTensor</a></td>
    <td>C++</td>
    <td>1.1 patch 16</td>
    <td><a href="http://www.oonumerics.org/FTensor/FTensor_gcc_integration_test.tar.gz">
         FTensor_gcc_integration_test.tar.gz</a></td>
    <td><a href="testing-ftensor.html">build and test guide</a></td>
</tr>
<tr><td><a href="http://www.gnu.org/software/emacs/">GNU Emacs</a></td>
    <td>C</td>
    <td>20.6</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
</tr>
<tr><td><a href="http://www.netlib.org/lapack/index.html">LAPACK</a></td>
    <td>Fortran</td>
    <td>3.0</td>
    <td><a href="http://www.netlib.org/lapack/lapack.tgz">LAPACK (testing programs)</a></td>
    <td><a href="testing-lapack.html">build and test guide</a></td>
</tr>
<tr><td><a href="http://www.kernel.org">Linux kernel</a></td>
    <td>C</td>
    <td>2.4.18</td>
    <td><a
    href="ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.18.tar.bz2">
    linux-2.4.18.tar.gz</a></td>
    <td>&nbsp;</td>
</tr>
<tr><td><a href="http://www.osl.iu.edu/research/mtl/">MTL</a></td>
    <td>C++</td>
    <td>2.12.2.-20</td>
    <td><a href="http://www.osl.iu.edu/research/mtl/download.php3">
        MTL (Download)</a>, with <a href="http://www.osl.iu.edu/MailArchives/mtl-devel/msg00311.php">patch</a></td>
    <td>&nbsp;</td>
</tr>
<tr><td><a href="http://www.acl.lanl.gov/pooma/">POOMA</a></td>
    <td>C++</td>
    <td>2.3.0</td>
    <td><a href="ftp://gcc.gnu.org/pub/gcc/infrastructure/pooma-gcc.tar.gz">pooma-gcc.tar.gz</a></td>
    <td><a href="testing-pooma.html">build and test guide</a></td>
</tr>
<tr><td><a href="http://www.trolltech.com/products/qt/index.html">Qt</a></td>
    <td>C++</td>
    <td>2.3.0</td>
    <td><a href="ftp://ftp.trolltech.com/qt/source/qt-x11-2.3.0.tar.gz">qt-x11-2.3.0.tar.gz</a></td>
    <td><a href="testing-qt.html">build and test guide</a></td>
</tr>
<tr><td><a href="http://root.cern.ch/">root</a></td>
    <td>C++</td>
    <td>3.01.00</td>
    <td><a href="http://root.cern.ch/root/Version301.html">
        root-3.01</a></td>
    <td>&nbsp;</td>
</tr>
</table>

<p>These selections were made for a variety of reasons.  The Linux kernel is
one of the most important pieces of free software, and kernel developers pay
careful attention to GCC performance.  It would be an embarrassment if GCC
did not compile the kernel correctly, out of the box.  The kernel
taxes many of the low-level aspects of GCC, as well as many GCC extensions,
including the extended assembly syntax, addresses of labels, and so forth.
(Historically, there have been kernel bugs, found only by more aggressive
optimization in new releases of GCC.  If such bugs are encountered, then
appropriate patches should be applied to the kernel before testing.)</p>

<p>GNU Emacs is portable to almost every system available, and is a complex
application-level C program, known to have very few bugs.</p>

<p>POOMA is a complex expression-template library that will tax the ability
of G++ to deal with templates, an area that has historically been buggy.
In addition, templates have historically taken inordinately much time and
memory at compile-time.  With the widespread prevalence of templates in
C++ programs, including the standard library, testing this area heavily is
vitally important. Pooma-gcc is pooma-2.3.0 plus some scripts which
simplify testing.</p>

<p>LAPACK is a well known linear algebra package that contains code
typical for large scale Fortran programs.</p>

<h3>Code Quality</h3>

<p>Historically, there has been no formal release criterion that took into
account performance of code generated by the compiler.  It is important that
the generated code performs approximately as well as previous releases.
Therefore, we will use the following benchmarks for measuring code
quality:</p>

<table align="center" border="1">
<tr><th align="left">Name</th>
    <th align="left">Language</th>
    <th align="left">Source URL</th>
</tr>
<tr><td>gzip 1.2.4a</td><td>C</td><td>&nbsp;</td>
</tr>
<tr><td>Stepanov</td><td>C++</td>
    <td><a href="ftp://ftp.kai.com/pub/benchmarks/stepanov_v1p2.C">
         stepanov_v1p2.C</a></td>
</tr>
<tr><td>LAPACK</td><td>Fortran</td>
    <td><a href="http://www.netlib.org/lapack/lapack.tgz">
        LAPACK 3.0 (timing programs)</a></td>
</tr>
</table>

<p>A Java benchmark is not required for this release since there is little
precedent for the behavior of the Java compiler.  For Java, functional
completeness and correctness are still more important than optimization.</p>

<p>In addition to the above benchmarks, the behavior of real
programs should be considered as well.  For that reason, the
behavior of the elliptic curve integer factorization program <a
href="ftp://ftp.loria.fr/pub/loria/eureca/tmp/GMP-ECM/ecm4c.c">ecm4c.c</a>,
which uses GNU mp, will be considered part of the release criteria.</p>

<p>The performance of the generated code of a release candidate should be
at least as good as that of past releases of GCC since 2.95.3 on the
benchmarks, and within at least 5% on the application tests.</p>

<h3>Compile-Time Performance</h3>

<p>There is a perception that current versions of GCC take longer to compile
programs than their 2.95.3 counterparts, and that they often use more memory
as well.  Compile-time performance is an important part of compiler quality.
It is not enough simply to provide additional optimizations; the compiler
must also continue to compile programs relatively quickly.  However, it
is to be expected that additional optimizations and additional features
will have a non-zero cost.</p>

<p>In order to measure compile-time performance, we will use the
following unit tests:</p>
<table align="center" border="1">
<tr><th align="left">Name</th>
    <th align="left">Language</th>
    <th align="left">Source</th>
    <th align="left">Flags</th>
    <th align="left">Comments</th>
</tr>
<tr><td>insn-attrtab.c</td>
    <td>C</td>
    <td>&nbsp;</td>
    <td>-O2</td>
    <td>This file contains a large machine-generated switch
        statement; it is a reasonable benchmark for testing flow
        optimizations and for handling large functions.</td>
</tr>
<tr><td>&nbsp;</td>
    <td>C++</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
</tr>
<tr><td>&nbsp;</td>
    <td>Fortran</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
</tr>
</table>

<p>In addition to these unit tests, time and peak memory usage used
when building the entire GNU Emacs distribution should be measured.</p>

<p>A release candidate's compile-time should not exceed GCC 2.95.3 by
more than 15%, and peak memory usage should not exceed that of GCC 2.95.3
by more than 25%.</p>

</body>
</html>