* GCC 3.3 release criteria
@ 2003-02-24 0:30 Kaveh R. Ghazi
2003-02-24 20:26 ` Dan Kegel
` (2 more replies)
0 siblings, 3 replies; 78+ messages in thread
From: Kaveh R. Ghazi @ 2003-02-24 0:30 UTC (permalink / raw)
To: gcc-patches, gcc; +Cc: mark
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> </td></tr>
<tr><td>Intel x86</td><td>RedHat Linux 6.2</td> <td>i686-pc-linux-gnu</td><td> </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> </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> </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> </td></tr>
<tr><td>Intel x86</td><td>Cygwin</td> <td>i686-pc-cygwin</td><td> </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> </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> </td>
<td> </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> </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> </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> </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> </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> </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> </td>
<td>C++</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr><td> </td>
<td>Fortran</td>
<td> </td>
<td> </td>
<td> </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>
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-24 0:30 GCC 3.3 release criteria Kaveh R. Ghazi
@ 2003-02-24 20:26 ` Dan Kegel
2003-02-24 20:44 ` Janis Johnson
2003-02-24 21:41 ` Jason R Thorpe
2003-02-25 2:49 ` Mark Mitchell
2 siblings, 1 reply; 78+ messages in thread
From: Dan Kegel @ 2003-02-24 20:26 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: gcc-patches, gcc, mark
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> </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> </td>
</tr>
Thanks,
Dan
(not subscribed)
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-24 20:26 ` Dan Kegel
@ 2003-02-24 20:44 ` Janis Johnson
2003-02-25 2:57 ` Mark Mitchell
0 siblings, 1 reply; 78+ messages in thread
From: Janis Johnson @ 2003-02-24 20:44 UTC (permalink / raw)
To: Dan Kegel; +Cc: Kaveh R. Ghazi, gcc-patches, gcc, mark
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> </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> </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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-24 0:30 GCC 3.3 release criteria Kaveh R. Ghazi
2003-02-24 20:26 ` Dan Kegel
@ 2003-02-24 21:41 ` Jason R Thorpe
2003-02-25 0:29 ` Kaveh R. Ghazi
2003-02-25 2:49 ` Mark Mitchell
2 siblings, 1 reply; 78+ messages in thread
From: Jason R Thorpe @ 2003-02-24 21:41 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: gcc-patches, gcc, mark
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>
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-24 21:41 ` Jason R Thorpe
@ 2003-02-25 0:29 ` Kaveh R. Ghazi
0 siblings, 0 replies; 78+ messages in thread
From: Kaveh R. Ghazi @ 2003-02-25 0:29 UTC (permalink / raw)
To: thorpej; +Cc: gcc-patches, gcc, mark
> 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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-24 0:30 GCC 3.3 release criteria Kaveh R. Ghazi
2003-02-24 20:26 ` Dan Kegel
2003-02-24 21:41 ` Jason R Thorpe
@ 2003-02-25 2:49 ` Mark Mitchell
2003-02-25 7:07 ` Matthias Klose
2003-02-25 16:47 ` Kaveh R. Ghazi
2 siblings, 2 replies; 78+ messages in thread
From: Mark Mitchell @ 2003-02-25 2:49 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: gcc
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-24 20:44 ` Janis Johnson
@ 2003-02-25 2:57 ` Mark Mitchell
2003-02-25 8:42 ` Eric Botcazou
2003-02-25 17:11 ` Janis Johnson
0 siblings, 2 replies; 78+ messages in thread
From: Mark Mitchell @ 2003-02-25 2:57 UTC (permalink / raw)
To: Janis Johnson; +Cc: Dan Kegel, Kaveh R. Ghazi, gcc-patches, gcc
> > 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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 2:49 ` Mark Mitchell
@ 2003-02-25 7:07 ` Matthias Klose
2003-02-25 16:23 ` Kaveh R. Ghazi
2003-02-25 16:47 ` Kaveh R. Ghazi
1 sibling, 1 reply; 78+ messages in thread
From: Matthias Klose @ 2003-02-25 7:07 UTC (permalink / raw)
To: Kaveh R. Ghazi, gcc
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 2:57 ` Mark Mitchell
@ 2003-02-25 8:42 ` Eric Botcazou
2003-02-25 17:11 ` Janis Johnson
1 sibling, 0 replies; 78+ messages in thread
From: Eric Botcazou @ 2003-02-25 8:42 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Janis Johnson, Dan Kegel, Kaveh R. Ghazi, gcc-patches, gcc
> 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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 7:07 ` Matthias Klose
@ 2003-02-25 16:23 ` Kaveh R. Ghazi
2003-02-25 17:23 ` Matthias Klose
0 siblings, 1 reply; 78+ messages in thread
From: Kaveh R. Ghazi @ 2003-02-25 16:23 UTC (permalink / raw)
To: doko, gcc
> 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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 2:49 ` Mark Mitchell
2003-02-25 7:07 ` Matthias Klose
@ 2003-02-25 16:47 ` Kaveh R. Ghazi
2003-02-25 17:24 ` Janis Johnson
2003-02-25 18:21 ` Janis Johnson
1 sibling, 2 replies; 78+ messages in thread
From: Kaveh R. Ghazi @ 2003-02-25 16:47 UTC (permalink / raw)
To: mark; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 2:57 ` Mark Mitchell
2003-02-25 8:42 ` Eric Botcazou
@ 2003-02-25 17:11 ` Janis Johnson
1 sibling, 0 replies; 78+ messages in thread
From: Janis Johnson @ 2003-02-25 17:11 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Janis Johnson, Dan Kegel, Kaveh R. Ghazi, gcc-patches, gcc
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 16:23 ` Kaveh R. Ghazi
@ 2003-02-25 17:23 ` Matthias Klose
2003-03-01 15:56 ` Kaveh R. Ghazi
0 siblings, 1 reply; 78+ messages in thread
From: Matthias Klose @ 2003-02-25 17:23 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: gcc
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> </td></tr>
+<tr><td>Intel x86</td><td>Debian GNU/Linux 3.0</td><td>i386-pc-linux-gnu</td><td> </td></tr>
<tr><td>Intel x86</td><td>RedHat Linux 6.2</td> <td>i686-pc-linux-gnu</td><td> </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> </td></tr>
<tr><td>Intel x86</td><td>Cygwin</td> <td>i686-pc-cygwin</td><td> </td></tr>
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 16:47 ` Kaveh R. Ghazi
@ 2003-02-25 17:24 ` Janis Johnson
2003-02-25 18:21 ` Janis Johnson
1 sibling, 0 replies; 78+ messages in thread
From: Janis Johnson @ 2003-02-25 17:24 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: mark, gcc
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 16:47 ` Kaveh R. Ghazi
2003-02-25 17:24 ` Janis Johnson
@ 2003-02-25 18:21 ` Janis Johnson
2003-02-25 22:20 ` Kaveh R. Ghazi
1 sibling, 1 reply; 78+ messages in thread
From: Janis Johnson @ 2003-02-25 18:21 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: mark, gcc
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>
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 18:21 ` Janis Johnson
@ 2003-02-25 22:20 ` Kaveh R. Ghazi
0 siblings, 0 replies; 78+ messages in thread
From: Kaveh R. Ghazi @ 2003-02-25 22:20 UTC (permalink / raw)
To: janis187; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 17:23 ` Matthias Klose
@ 2003-03-01 15:56 ` Kaveh R. Ghazi
2003-03-01 16:05 ` Ben Collins
2003-03-01 17:56 ` Matthias Klose
0 siblings, 2 replies; 78+ messages in thread
From: Kaveh R. Ghazi @ 2003-03-01 15:56 UTC (permalink / raw)
To: doko; +Cc: bcollins, gcc
> 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> </td></tr>
> +<tr><td>Intel x86</td><td>Debian GNU/Linux 3.0</td><td>i386-pc-linux-gnu</td><td> </td></tr>
> <tr><td>Intel x86</td><td>RedHat Linux 6.2</td> <td>i686-pc-linux-gnu</td><td> </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> </td></tr>
> <tr><td>Intel x86</td><td>Cygwin</td> <td>i686-pc-cygwin</td><td> </td></tr>
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-03-01 15:56 ` Kaveh R. Ghazi
@ 2003-03-01 16:05 ` Ben Collins
2003-03-01 16:21 ` Kaveh R. Ghazi
2003-03-01 17:56 ` Matthias Klose
1 sibling, 1 reply; 78+ messages in thread
From: Ben Collins @ 2003-03-01 16:05 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: doko, gcc
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/
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-03-01 16:05 ` Ben Collins
@ 2003-03-01 16:21 ` Kaveh R. Ghazi
2003-03-01 16:27 ` Ben Collins
0 siblings, 1 reply; 78+ messages in thread
From: Kaveh R. Ghazi @ 2003-03-01 16:21 UTC (permalink / raw)
To: bcollins; +Cc: doko, gcc
> 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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-03-01 16:21 ` Kaveh R. Ghazi
@ 2003-03-01 16:27 ` Ben Collins
2003-03-04 14:49 ` Kaveh R. Ghazi
0 siblings, 1 reply; 78+ messages in thread
From: Ben Collins @ 2003-03-01 16:27 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: doko, gcc
> 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/
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-03-01 15:56 ` Kaveh R. Ghazi
2003-03-01 16:05 ` Ben Collins
@ 2003-03-01 17:56 ` Matthias Klose
2003-03-04 14:55 ` Kaveh R. Ghazi
1 sibling, 1 reply; 78+ messages in thread
From: Matthias Klose @ 2003-03-01 17:56 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: bcollins, gcc, debian-gcc
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-03-01 16:27 ` Ben Collins
@ 2003-03-04 14:49 ` Kaveh R. Ghazi
2003-03-04 15:19 ` Ben Collins
0 siblings, 1 reply; 78+ messages in thread
From: Kaveh R. Ghazi @ 2003-03-04 14:49 UTC (permalink / raw)
To: bcollins; +Cc: doko, gcc
> 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> </td></tr>
<tr><td>Intel x86</td><td>Cygwin</td> <td>i686-pc-cygwin</td><td> </td></tr>
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-03-01 17:56 ` Matthias Klose
@ 2003-03-04 14:55 ` Kaveh R. Ghazi
2003-03-09 23:34 ` Matthias Klose
0 siblings, 1 reply; 78+ messages in thread
From: Kaveh R. Ghazi @ 2003-03-04 14:55 UTC (permalink / raw)
To: doko; +Cc: bcollins, debian-gcc, gcc
> 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> </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> </td></tr>
<tr><td>Intel x86</td><td>FreeBSD 4.5</td>
<td>i386-unknown-freebsd4.5</td>
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-03-04 14:49 ` Kaveh R. Ghazi
@ 2003-03-04 15:19 ` Ben Collins
0 siblings, 0 replies; 78+ messages in thread
From: Ben Collins @ 2003-03-04 15:19 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: doko, gcc
> 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/
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-03-04 14:55 ` Kaveh R. Ghazi
@ 2003-03-09 23:34 ` Matthias Klose
2003-03-10 1:21 ` Kaveh R. Ghazi
0 siblings, 1 reply; 78+ messages in thread
From: Matthias Klose @ 2003-03-09 23:34 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: bcollins, debian-gcc, gcc
[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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-03-09 23:34 ` Matthias Klose
@ 2003-03-10 1:21 ` Kaveh R. Ghazi
0 siblings, 0 replies; 78+ messages in thread
From: Kaveh R. Ghazi @ 2003-03-10 1:21 UTC (permalink / raw)
To: doko; +Cc: bcollins, debian-gcc, gcc
> 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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-03-10 18:08 ` Janis Johnson
@ 2003-03-10 18:22 ` Kaveh R. Ghazi
0 siblings, 0 replies; 78+ messages in thread
From: Kaveh R. Ghazi @ 2003-03-10 18:22 UTC (permalink / raw)
To: janis187; +Cc: dave, gcc
> 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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-03-10 3:20 ` Kaveh R. Ghazi
@ 2003-03-10 18:08 ` Janis Johnson
2003-03-10 18:22 ` Kaveh R. Ghazi
0 siblings, 1 reply; 78+ messages in thread
From: Janis Johnson @ 2003-03-10 18:08 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: dave, gcc
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-03-10 1:22 John David Anglin
@ 2003-03-10 3:20 ` Kaveh R. Ghazi
2003-03-10 18:08 ` Janis Johnson
0 siblings, 1 reply; 78+ messages in thread
From: Kaveh R. Ghazi @ 2003-03-10 3:20 UTC (permalink / raw)
To: dave, gcc
> 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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
@ 2003-03-10 1:22 John David Anglin
2003-03-10 3:20 ` Kaveh R. Ghazi
0 siblings, 1 reply; 78+ messages in thread
From: John David Anglin @ 2003-03-10 1:22 UTC (permalink / raw)
To: gcc; +Cc: ghazi
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)
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-03-01 13:16 ` Bernd Schmidt
@ 2003-03-01 13:59 ` Richard Earnshaw
0 siblings, 0 replies; 78+ messages in thread
From: Richard Earnshaw @ 2003-03-01 13:59 UTC (permalink / raw)
To: Bernd Schmidt
Cc: Richard.Earnshaw, Steven Bosscher, Franz Sirl, Daniel Jacobowitz,
Andi Kleen, Kaveh R. Ghazi, gcc
> 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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 11:18 ` Richard Earnshaw
2003-02-25 11:32 ` Gabriel Dos Reis
@ 2003-03-01 13:16 ` Bernd Schmidt
2003-03-01 13:59 ` Richard Earnshaw
1 sibling, 1 reply; 78+ messages in thread
From: Bernd Schmidt @ 2003-03-01 13:16 UTC (permalink / raw)
To: Richard.Earnshaw
Cc: Steven Bosscher, Franz Sirl, Daniel Jacobowitz, Andi Kleen,
Kaveh R. Ghazi, gcc
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
@ 2003-02-26 22:50 Robert Dewar
0 siblings, 0 replies; 78+ messages in thread
From: Robert Dewar @ 2003-02-26 22:50 UTC (permalink / raw)
To: dewar, mstump; +Cc: gcc, mattias
> 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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-26 15:55 Robert Dewar
@ 2003-02-26 22:24 ` Mike Stump
0 siblings, 0 replies; 78+ messages in thread
From: Mike Stump @ 2003-02-26 22:24 UTC (permalink / raw)
To: Robert Dewar; +Cc: gcc, mattias
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?
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
@ 2003-02-26 15:55 Robert Dewar
2003-02-26 22:24 ` Mike Stump
0 siblings, 1 reply; 78+ messages in thread
From: Robert Dewar @ 2003-02-26 15:55 UTC (permalink / raw)
To: gcc, mattias
> 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!
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 23:43 ` Matt Austern
2003-02-25 23:45 ` Dale Johannesen
@ 2003-02-26 11:45 ` Mattias Engdegård
1 sibling, 0 replies; 78+ messages in thread
From: Mattias Engdegård @ 2003-02-26 11:45 UTC (permalink / raw)
To: gcc
>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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
@ 2003-02-26 2:42 Robert Dewar
0 siblings, 0 replies; 78+ messages in thread
From: Robert Dewar @ 2003-02-26 2:42 UTC (permalink / raw)
To: austern, drow; +Cc: gcc, hch, lars.segerlund, m.hayes, stuart, tm_gccmail
> 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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 12:13 ` Franz Sirl
@ 2003-02-26 1:14 ` Richard Henderson
0 siblings, 0 replies; 78+ messages in thread
From: Richard Henderson @ 2003-02-26 1:14 UTC (permalink / raw)
To: Franz Sirl
Cc: Richard.Earnshaw, Daniel Jacobowitz, Andi Kleen, Kaveh R. Ghazi, gcc
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~
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 22:01 ` tm_gccmail
@ 2003-02-26 0:23 ` Richard Henderson
0 siblings, 0 replies; 78+ messages in thread
From: Richard Henderson @ 2003-02-26 0:23 UTC (permalink / raw)
To: tm_gccmail
Cc: Matt Austern, Michael Hayes, Lars Segerlund, gcc, Stuart Hastings
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~
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 22:07 ` Stuart Hastings
@ 2003-02-26 0:11 ` Richard Henderson
0 siblings, 0 replies; 78+ messages in thread
From: Richard Henderson @ 2003-02-26 0:11 UTC (permalink / raw)
To: Stuart Hastings
Cc: Matt Austern, Michael Hayes, tm_gccmail, Lars Segerlund, gcc
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~
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 23:43 ` Matt Austern
@ 2003-02-25 23:45 ` Dale Johannesen
2003-02-26 11:45 ` Mattias Engdegård
1 sibling, 0 replies; 78+ messages in thread
From: Dale Johannesen @ 2003-02-25 23:45 UTC (permalink / raw)
To: Matt Austern
Cc: Dale Johannesen, Daniel Jacobowitz, Christoph Hellwig,
Michael Hayes, tm_gccmail, Lars Segerlund, gcc, Stuart Hastings
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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 23:09 ` Daniel Jacobowitz
@ 2003-02-25 23:43 ` Matt Austern
2003-02-25 23:45 ` Dale Johannesen
2003-02-26 11:45 ` Mattias Engdegård
0 siblings, 2 replies; 78+ messages in thread
From: Matt Austern @ 2003-02-25 23:43 UTC (permalink / raw)
To: Daniel Jacobowitz
Cc: Christoph Hellwig, Michael Hayes, tm_gccmail, Lars Segerlund,
gcc, Stuart Hastings
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 22:58 ` Michel LESPINASSE
@ 2003-02-25 23:09 ` Daniel Jacobowitz
2003-02-25 23:43 ` Matt Austern
0 siblings, 1 reply; 78+ messages in thread
From: Daniel Jacobowitz @ 2003-02-25 23:09 UTC (permalink / raw)
To: Matt Austern
Cc: Christoph Hellwig, Michael Hayes, tm_gccmail, Lars Segerlund,
gcc, Stuart Hastings
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 22:35 ` Matt Austern
@ 2003-02-25 22:58 ` Michel LESPINASSE
2003-02-25 23:09 ` Daniel Jacobowitz
0 siblings, 1 reply; 78+ messages in thread
From: Michel LESPINASSE @ 2003-02-25 22:58 UTC (permalink / raw)
To: Matt Austern
Cc: Christoph Hellwig, Michael Hayes, tm_gccmail, Lars Segerlund,
gcc, Stuart Hastings
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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 22:22 ` Christoph Hellwig
@ 2003-02-25 22:35 ` Matt Austern
2003-02-25 22:58 ` Michel LESPINASSE
0 siblings, 1 reply; 78+ messages in thread
From: Matt Austern @ 2003-02-25 22:35 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Michael Hayes, tm_gccmail, Lars Segerlund, gcc, Stuart Hastings
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 21:09 ` Matt Austern
2003-02-25 22:01 ` tm_gccmail
2003-02-25 22:07 ` Stuart Hastings
@ 2003-02-25 22:22 ` Christoph Hellwig
2003-02-25 22:35 ` Matt Austern
2 siblings, 1 reply; 78+ messages in thread
From: Christoph Hellwig @ 2003-02-25 22:22 UTC (permalink / raw)
To: Matt Austern
Cc: Michael Hayes, tm_gccmail, Lars Segerlund, gcc, Stuart Hastings
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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 21:09 ` Matt Austern
2003-02-25 22:01 ` tm_gccmail
@ 2003-02-25 22:07 ` Stuart Hastings
2003-02-26 0:11 ` Richard Henderson
2003-02-25 22:22 ` Christoph Hellwig
2 siblings, 1 reply; 78+ messages in thread
From: Stuart Hastings @ 2003-02-25 22:07 UTC (permalink / raw)
To: Matt Austern; +Cc: Michael Hayes, tm_gccmail, Lars Segerlund, gcc
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 21:09 ` Matt Austern
@ 2003-02-25 22:01 ` tm_gccmail
2003-02-26 0:23 ` Richard Henderson
2003-02-25 22:07 ` Stuart Hastings
2003-02-25 22:22 ` Christoph Hellwig
2 siblings, 1 reply; 78+ messages in thread
From: tm_gccmail @ 2003-02-25 22:01 UTC (permalink / raw)
To: Matt Austern; +Cc: Michael Hayes, Lars Segerlund, gcc, Stuart Hastings
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 20:58 ` Michael Hayes
@ 2003-02-25 21:09 ` Matt Austern
2003-02-25 22:01 ` tm_gccmail
` (2 more replies)
0 siblings, 3 replies; 78+ messages in thread
From: Matt Austern @ 2003-02-25 21:09 UTC (permalink / raw)
To: Michael Hayes; +Cc: tm_gccmail, Lars Segerlund, gcc, Stuart Hastings
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 19:31 ` tm_gccmail
@ 2003-02-25 20:58 ` Michael Hayes
2003-02-25 21:09 ` Matt Austern
0 siblings, 1 reply; 78+ messages in thread
From: Michael Hayes @ 2003-02-25 20:58 UTC (permalink / raw)
To: tm_gccmail; +Cc: Lars Segerlund, gcc
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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 11:55 ` Lars Segerlund
@ 2003-02-25 19:31 ` tm_gccmail
2003-02-25 20:58 ` Michael Hayes
0 siblings, 1 reply; 78+ messages in thread
From: tm_gccmail @ 2003-02-25 19:31 UTC (permalink / raw)
To: Lars Segerlund; +Cc: gcc
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 14:17 ` Richard Earnshaw
@ 2003-02-25 18:48 ` Joseph S. Myers
0 siblings, 0 replies; 78+ messages in thread
From: Joseph S. Myers @ 2003-02-25 18:48 UTC (permalink / raw)
To: Richard.Earnshaw; +Cc: gcc
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 15:28 ` Richard Earnshaw
@ 2003-02-25 15:42 ` Fergus Henderson
0 siblings, 0 replies; 78+ messages in thread
From: Fergus Henderson @ 2003-02-25 15:42 UTC (permalink / raw)
To: Richard.Earnshaw
Cc: Gabriel Dos Reis, Steven Bosscher, Franz Sirl, Daniel Jacobowitz,
Andi Kleen, Kaveh R. Ghazi, gcc
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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 14:42 ` Gabriel Dos Reis
@ 2003-02-25 15:28 ` Richard Earnshaw
2003-02-25 15:42 ` Fergus Henderson
0 siblings, 1 reply; 78+ messages in thread
From: Richard Earnshaw @ 2003-02-25 15:28 UTC (permalink / raw)
To: Gabriel Dos Reis
Cc: Richard.Earnshaw, Steven Bosscher, Franz Sirl, Daniel Jacobowitz,
Andi Kleen, Kaveh R. Ghazi, gcc
> | 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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
@ 2003-02-25 14:45 Paolo Bonzini
0 siblings, 0 replies; 78+ messages in thread
From: Paolo Bonzini @ 2003-02-25 14:45 UTC (permalink / raw)
To: schwab, gcc
> 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.
--
|_ _ _ __
|_)(_)| ) ;'_.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 14:04 ` Richard Earnshaw
2003-02-25 14:17 ` Richard Earnshaw
@ 2003-02-25 14:42 ` Gabriel Dos Reis
2003-02-25 15:28 ` Richard Earnshaw
1 sibling, 1 reply; 78+ messages in thread
From: Gabriel Dos Reis @ 2003-02-25 14:42 UTC (permalink / raw)
To: Richard.Earnshaw
Cc: Steven Bosscher, Franz Sirl, Daniel Jacobowitz, Andi Kleen,
Kaveh R. Ghazi, gcc
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 14:04 ` Richard Earnshaw
@ 2003-02-25 14:17 ` Richard Earnshaw
2003-02-25 18:48 ` Joseph S. Myers
2003-02-25 14:42 ` Gabriel Dos Reis
1 sibling, 1 reply; 78+ messages in thread
From: Richard Earnshaw @ 2003-02-25 14:17 UTC (permalink / raw)
To: Gabriel Dos Reis
Cc: Richard.Earnshaw, Steven Bosscher, Franz Sirl, Daniel Jacobowitz,
Andi Kleen, Kaveh R. Ghazi, gcc
> 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());}
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 12:36 ` Gabriel Dos Reis
@ 2003-02-25 14:04 ` Richard Earnshaw
2003-02-25 14:17 ` Richard Earnshaw
2003-02-25 14:42 ` Gabriel Dos Reis
0 siblings, 2 replies; 78+ messages in thread
From: Richard Earnshaw @ 2003-02-25 14:04 UTC (permalink / raw)
To: Gabriel Dos Reis
Cc: Richard.Earnshaw, Steven Bosscher, Franz Sirl, Daniel Jacobowitz,
Andi Kleen, Kaveh R. Ghazi, gcc
> | 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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 12:10 ` Kean Johnston
@ 2003-02-25 13:51 ` Andreas Schwab
0 siblings, 0 replies; 78+ messages in thread
From: Andreas Schwab @ 2003-02-25 13:51 UTC (permalink / raw)
To: Kean Johnston; +Cc: gcc
"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."
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
@ 2003-02-25 13:12 Robert Dewar
0 siblings, 0 replies; 78+ messages in thread
From: Robert Dewar @ 2003-02-25 13:12 UTC (permalink / raw)
To: dewar, gdr; +Cc: gcc, lars.segerlund
> 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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 12:31 Robert Dewar
@ 2003-02-25 12:58 ` Gabriel Dos Reis
0 siblings, 0 replies; 78+ messages in thread
From: Gabriel Dos Reis @ 2003-02-25 12:58 UTC (permalink / raw)
To: Robert Dewar; +Cc: gcc, lars.segerlund
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 12:30 ` Richard Earnshaw
@ 2003-02-25 12:36 ` Gabriel Dos Reis
2003-02-25 14:04 ` Richard Earnshaw
0 siblings, 1 reply; 78+ messages in thread
From: Gabriel Dos Reis @ 2003-02-25 12:36 UTC (permalink / raw)
To: Richard.Earnshaw
Cc: Steven Bosscher, Franz Sirl, Daniel Jacobowitz, Andi Kleen,
Kaveh R. Ghazi, gcc
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
@ 2003-02-25 12:31 Robert Dewar
2003-02-25 12:58 ` Gabriel Dos Reis
0 siblings, 1 reply; 78+ messages in thread
From: Robert Dewar @ 2003-02-25 12:31 UTC (permalink / raw)
To: gcc, lars.segerlund
> 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".
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 11:32 ` Gabriel Dos Reis
@ 2003-02-25 12:30 ` Richard Earnshaw
2003-02-25 12:36 ` Gabriel Dos Reis
0 siblings, 1 reply; 78+ messages in thread
From: Richard Earnshaw @ 2003-02-25 12:30 UTC (permalink / raw)
To: Gabriel Dos Reis
Cc: Richard.Earnshaw, Steven Bosscher, Franz Sirl, Daniel Jacobowitz,
Andi Kleen, Kaveh R. Ghazi, gcc
> 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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 10:34 ` Richard Earnshaw
2003-02-25 10:57 ` Steven Bosscher
2003-02-25 12:10 ` Kean Johnston
@ 2003-02-25 12:13 ` Franz Sirl
2003-02-26 1:14 ` Richard Henderson
2 siblings, 1 reply; 78+ messages in thread
From: Franz Sirl @ 2003-02-25 12:13 UTC (permalink / raw)
To: Richard.Earnshaw
Cc: Daniel Jacobowitz, Andi Kleen, Kaveh R. Ghazi, gcc, Richard.Earnshaw
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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* RE: GCC 3.3 release criteria
2003-02-25 10:34 ` Richard Earnshaw
2003-02-25 10:57 ` Steven Bosscher
@ 2003-02-25 12:10 ` Kean Johnston
2003-02-25 13:51 ` Andreas Schwab
2003-02-25 12:13 ` Franz Sirl
2 siblings, 1 reply; 78+ messages in thread
From: Kean Johnston @ 2003-02-25 12:10 UTC (permalink / raw)
To: Richard.Earnshaw, 'Franz Sirl'
Cc: 'Daniel Jacobowitz', 'Andi Kleen',
'Kaveh R. Ghazi',
gcc
> 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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 11:30 ` Gabriel Dos Reis
@ 2003-02-25 11:55 ` Lars Segerlund
2003-02-25 19:31 ` tm_gccmail
0 siblings, 1 reply; 78+ messages in thread
From: Lars Segerlund @ 2003-02-25 11:55 UTC (permalink / raw)
To: gcc
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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 11:18 ` Richard Earnshaw
@ 2003-02-25 11:32 ` Gabriel Dos Reis
2003-02-25 12:30 ` Richard Earnshaw
2003-03-01 13:16 ` Bernd Schmidt
1 sibling, 1 reply; 78+ messages in thread
From: Gabriel Dos Reis @ 2003-02-25 11:32 UTC (permalink / raw)
To: Richard.Earnshaw
Cc: Steven Bosscher, Franz Sirl, Daniel Jacobowitz, Andi Kleen,
Kaveh R. Ghazi, gcc
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 10:57 ` Steven Bosscher
2003-02-25 11:18 ` Richard Earnshaw
@ 2003-02-25 11:30 ` Gabriel Dos Reis
2003-02-25 11:55 ` Lars Segerlund
1 sibling, 1 reply; 78+ messages in thread
From: Gabriel Dos Reis @ 2003-02-25 11:30 UTC (permalink / raw)
To: Steven Bosscher
Cc: Richard.Earnshaw, Franz Sirl, Daniel Jacobowitz, Andi Kleen,
Kaveh R. Ghazi, gcc
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 10:57 ` Steven Bosscher
@ 2003-02-25 11:18 ` Richard Earnshaw
2003-02-25 11:32 ` Gabriel Dos Reis
2003-03-01 13:16 ` Bernd Schmidt
2003-02-25 11:30 ` Gabriel Dos Reis
1 sibling, 2 replies; 78+ messages in thread
From: Richard Earnshaw @ 2003-02-25 11:18 UTC (permalink / raw)
To: Steven Bosscher
Cc: Richard.Earnshaw, Franz Sirl, Daniel Jacobowitz, Andi Kleen,
Kaveh R. Ghazi, gcc
> 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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-25 10:34 ` Richard Earnshaw
@ 2003-02-25 10:57 ` Steven Bosscher
2003-02-25 11:18 ` Richard Earnshaw
2003-02-25 11:30 ` Gabriel Dos Reis
2003-02-25 12:10 ` Kean Johnston
2003-02-25 12:13 ` Franz Sirl
2 siblings, 2 replies; 78+ messages in thread
From: Steven Bosscher @ 2003-02-25 10:57 UTC (permalink / raw)
To: Richard.Earnshaw
Cc: Franz Sirl, Daniel Jacobowitz, Andi Kleen, Kaveh R. Ghazi, gcc
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-24 21:30 ` Franz Sirl
@ 2003-02-25 10:34 ` Richard Earnshaw
2003-02-25 10:57 ` Steven Bosscher
` (2 more replies)
0 siblings, 3 replies; 78+ messages in thread
From: Richard Earnshaw @ 2003-02-25 10:34 UTC (permalink / raw)
To: Franz Sirl
Cc: Daniel Jacobowitz, Andi Kleen, Kaveh R. Ghazi, gcc, 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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-24 23:56 ` Kaveh R. Ghazi
@ 2003-02-25 0:32 ` Andi Kleen
0 siblings, 0 replies; 78+ messages in thread
From: Andi Kleen @ 2003-02-25 0:32 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: ak, gcc
> 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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-24 20:33 ` Andi Kleen
2003-02-24 20:37 ` Jakub Jelinek
2003-02-24 20:47 ` Daniel Jacobowitz
@ 2003-02-24 23:56 ` Kaveh R. Ghazi
2003-02-25 0:32 ` Andi Kleen
2 siblings, 1 reply; 78+ messages in thread
From: Kaveh R. Ghazi @ 2003-02-24 23:56 UTC (permalink / raw)
To: ak; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-24 20:47 ` Daniel Jacobowitz
@ 2003-02-24 21:30 ` Franz Sirl
2003-02-25 10:34 ` Richard Earnshaw
0 siblings, 1 reply; 78+ messages in thread
From: Franz Sirl @ 2003-02-24 21:30 UTC (permalink / raw)
To: Daniel Jacobowitz, Andi Kleen; +Cc: Kaveh R. Ghazi, gcc
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.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-24 20:33 ` Andi Kleen
2003-02-24 20:37 ` Jakub Jelinek
@ 2003-02-24 20:47 ` Daniel Jacobowitz
2003-02-24 21:30 ` Franz Sirl
2003-02-24 23:56 ` Kaveh R. Ghazi
2 siblings, 1 reply; 78+ messages in thread
From: Daniel Jacobowitz @ 2003-02-24 20:47 UTC (permalink / raw)
To: Andi Kleen; +Cc: Kaveh R. Ghazi, gcc
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
2003-02-24 20:33 ` Andi Kleen
@ 2003-02-24 20:37 ` Jakub Jelinek
2003-02-24 20:47 ` Daniel Jacobowitz
2003-02-24 23:56 ` Kaveh R. Ghazi
2 siblings, 0 replies; 78+ messages in thread
From: Jakub Jelinek @ 2003-02-24 20:37 UTC (permalink / raw)
To: Andi Kleen; +Cc: Kaveh R. Ghazi, gcc
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: GCC 3.3 release criteria
[not found] <200302232354.SAA19348@caip.rutgers.edu.suse.lists.egcs-patches>
@ 2003-02-24 20:33 ` Andi Kleen
2003-02-24 20:37 ` Jakub Jelinek
` (2 more replies)
0 siblings, 3 replies; 78+ messages in thread
From: Andi Kleen @ 2003-02-24 20:33 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: gcc
"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
^ permalink raw reply [flat|nested] 78+ messages in thread
end of thread, other threads:[~2003-03-10 18:08 UTC | newest]
Thread overview: 78+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-02-24 0:30 GCC 3.3 release criteria Kaveh R. Ghazi
2003-02-24 20:26 ` Dan Kegel
2003-02-24 20:44 ` Janis Johnson
2003-02-25 2:57 ` Mark Mitchell
2003-02-25 8:42 ` Eric Botcazou
2003-02-25 17:11 ` Janis Johnson
2003-02-24 21:41 ` Jason R Thorpe
2003-02-25 0:29 ` Kaveh R. Ghazi
2003-02-25 2:49 ` Mark Mitchell
2003-02-25 7:07 ` Matthias Klose
2003-02-25 16:23 ` Kaveh R. Ghazi
2003-02-25 17:23 ` Matthias Klose
2003-03-01 15:56 ` Kaveh R. Ghazi
2003-03-01 16:05 ` Ben Collins
2003-03-01 16:21 ` Kaveh R. Ghazi
2003-03-01 16:27 ` Ben Collins
2003-03-04 14:49 ` Kaveh R. Ghazi
2003-03-04 15:19 ` Ben Collins
2003-03-01 17:56 ` Matthias Klose
2003-03-04 14:55 ` Kaveh R. Ghazi
2003-03-09 23:34 ` Matthias Klose
2003-03-10 1:21 ` Kaveh R. Ghazi
2003-02-25 16:47 ` Kaveh R. Ghazi
2003-02-25 17:24 ` Janis Johnson
2003-02-25 18:21 ` Janis Johnson
2003-02-25 22:20 ` Kaveh R. Ghazi
[not found] <200302232354.SAA19348@caip.rutgers.edu.suse.lists.egcs-patches>
2003-02-24 20:33 ` Andi Kleen
2003-02-24 20:37 ` Jakub Jelinek
2003-02-24 20:47 ` Daniel Jacobowitz
2003-02-24 21:30 ` Franz Sirl
2003-02-25 10:34 ` Richard Earnshaw
2003-02-25 10:57 ` Steven Bosscher
2003-02-25 11:18 ` Richard Earnshaw
2003-02-25 11:32 ` Gabriel Dos Reis
2003-02-25 12:30 ` Richard Earnshaw
2003-02-25 12:36 ` Gabriel Dos Reis
2003-02-25 14:04 ` Richard Earnshaw
2003-02-25 14:17 ` Richard Earnshaw
2003-02-25 18:48 ` Joseph S. Myers
2003-02-25 14:42 ` Gabriel Dos Reis
2003-02-25 15:28 ` Richard Earnshaw
2003-02-25 15:42 ` Fergus Henderson
2003-03-01 13:16 ` Bernd Schmidt
2003-03-01 13:59 ` Richard Earnshaw
2003-02-25 11:30 ` Gabriel Dos Reis
2003-02-25 11:55 ` Lars Segerlund
2003-02-25 19:31 ` tm_gccmail
2003-02-25 20:58 ` Michael Hayes
2003-02-25 21:09 ` Matt Austern
2003-02-25 22:01 ` tm_gccmail
2003-02-26 0:23 ` Richard Henderson
2003-02-25 22:07 ` Stuart Hastings
2003-02-26 0:11 ` Richard Henderson
2003-02-25 22:22 ` Christoph Hellwig
2003-02-25 22:35 ` Matt Austern
2003-02-25 22:58 ` Michel LESPINASSE
2003-02-25 23:09 ` Daniel Jacobowitz
2003-02-25 23:43 ` Matt Austern
2003-02-25 23:45 ` Dale Johannesen
2003-02-26 11:45 ` Mattias Engdegård
2003-02-25 12:10 ` Kean Johnston
2003-02-25 13:51 ` Andreas Schwab
2003-02-25 12:13 ` Franz Sirl
2003-02-26 1:14 ` Richard Henderson
2003-02-24 23:56 ` Kaveh R. Ghazi
2003-02-25 0:32 ` Andi Kleen
2003-02-25 12:31 Robert Dewar
2003-02-25 12:58 ` Gabriel Dos Reis
2003-02-25 13:12 Robert Dewar
2003-02-25 14:45 Paolo Bonzini
2003-02-26 2:42 Robert Dewar
2003-02-26 15:55 Robert Dewar
2003-02-26 22:24 ` Mike Stump
2003-02-26 22:50 Robert Dewar
2003-03-10 1:22 John David Anglin
2003-03-10 3:20 ` Kaveh R. Ghazi
2003-03-10 18:08 ` Janis Johnson
2003-03-10 18:22 ` Kaveh R. Ghazi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).