This is the mail archive of the
mailing list for the GCC project.
Re: GCC 3.2
- From: Phil Edwards <phil at jaj dot com>
- To: law at redhat dot com, bkoz at redhat dot com
- Cc: Janis Johnson <janis187 at us dot ibm dot com>, Jakub Jelinek <jakub at redhat dot com>, Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>, Mark Mitchell <mark at codesourcery dot com>, gcc at gcc dot gnu dot org, "Kevin B. Hendricks" <kevin dot hendricks at sympatico dot ca>
- Date: Mon, 19 Aug 2002 14:41:22 -0400
- Subject: Re: GCC 3.2
- References: <20020812164321.A4428@us.ibm.com> <200208131649.g7DGnkK09005@porcupine.slc.redhat.com>
On Tue, Aug 13, 2002 at 10:49:46AM -0600, Jeff Law wrote:
> Right. That's one of the reasons why I mentioned in an earlier message
> that we need a test which verifies that all of the exported functions
> in libstdc++ (and libgcc) are maintained over time -- which has the
> side effect of being a reasonable tester for name mangling changes.
> We need ways to verify structure layouts aren't changing, etc etc.
In message <20020812164321.A4428@us.ibm.com>, Janis Johnson writes:
> >and new compilers available when running the tests. I'm not at all sure
> >how to set up such tests for use with GCC. The test harness needs to
> >know about two compilers under test rather than one,
For some time now my nightly autocrasher[*] has built both the current trunk
and the current 3.whatever-the-previous-release-was branch. I've started
comparing exported symbol information from the libstdc++.so's from both
builds. (See the libstdc++ list archives of the last week or so; posts
from Benjamin and Ulrich and myself.)
I've verified that changing the size of an exported symbol triggers the
regression detection. Work yet to be done:
1) Test for layout changes, not just size changes.
2) Find a way of putting this into the v3 repository.
I've no ideas on (1). For (2) I'll be posting some thoughts on the v3
[*] "autobuilder" is just too positive and uplifing a name for something as
hacky as what I wrote.
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
- Edsger Dijkstra, 1930-2002