Successful compilation

Successful compilation

[Russell Davidson]

I successfully built and installed egcs, snapshot 980406, on the following
configuration:

i686-pc-linux-gnulibc1

(output of config.guess).

The test suite showed a few unexpected errors, as follows:
FAIL: gcc.c-torture/compile/980329-1.c,  -O2  
FAIL: gcc.c-torture/compile/980329-1.c,  -O2 -fomit-frame-pointer -finline-functions  
FAIL: gcc.c-torture/compile/980329-1.c,  -O2 -fomit-frame-pointer -finline-functions -funroll-loops  
FAIL: gcc.c-torture/compile/980329-1.c,  -O2 -g  
FAIL: gcc.dg/980226-1.c (test for excess errors)
FAIL: g++.eh/flow1.C  Execution test
FAIL: g++.eh/new1.C  Execution test
FAIL: g++.eh/pdel1.C  Execution test
FAIL: g++.eh/pdel2.C  Execution test
FAIL: g++.eh/spec2.C  Execution test
FAIL: g++.eh/spec3.C  Execution test
FAIL: g++.eh/spec4.C  Execution test
FAIL: g++.mike/dyncast1.C  Execution test
FAIL: g++.mike/dyncast2.C  Execution test
FAIL: g++.mike/eh10.C  Execution test
FAIL: g++.mike/eh2.C  Execution test
FAIL: g++.mike/eh23.C  Execution test
FAIL: g++.mike/eh29.C  Execution test
FAIL: g++.mike/eh3.C  Execution test
FAIL: g++.mike/eh33.C  Execution test
FAIL: g++.mike/eh39.C  Execution test
FAIL: g++.mike/eh40.C  Execution test
FAIL: g++.mike/eh41.C  Execution test
FAIL: g++.mike/eh42.C  Execution test
FAIL: g++.mike/eh5.C  Execution test
FAIL: g++.mike/eh50.C  Execution test
FAIL: g++.mike/eh51.C  Execution test
FAIL: g++.mike/eh6.C  Execution test

Hope this is useful. 

Russell Davidson                    email: russell@ehess.cnrs-mrs.fr
GREQAM,
Centre de la Vieille Charite,       telephone: +33-4.91.14.07.40 
F-13002 Marseille                   fax:       +33-4.91.90.02.27

Re: Successful compilation

[Jeffrey A Law]

  In message < Pine.LNX.3.96.980410200209.32572A-100000@russell.cnrs-mrs.fr >you 
write:
  > I successfully built and installed egcs, snapshot 980406, on the following
  > configuration:
  > 
  > i686-pc-linux-gnulibc1
  > 
  > (output of config.guess).
  > 
[ ... ]
I suspect most of the eh failures will go away if you get a more
recent version of the assembler.

jeff

Successful Compilation

[Walter Landry]

Greetings,

First of all, I would like to thank each and every one of you.  I've
constructed a tensor library using a number of C++ template tricks.
Until recently, gcc would not compile it (PR 2494).  I was stuck using
proprietary compilers, causing me no end of grief.  A week ago, I
downloaded gcc-3_1-branch and, lo and behold, it now works.  Huzzah!
It still gives a warning about implicit typenames, but I can live with
that.  Since I've tested this library on more compilers than you can
shake a stick at, I think that is a bug in gcc.

In any case, I noticed that there is a list of libraries that GCC 3.1
is being tested against.  One of the implicit goals seems to be good
template support.  Since my library seems to stress the template
support more than the other libraries (as I said, gcc only recently
started compiling it), I thought it might be useful to the gcc team as
a test.

I have already written a fairly comprehensive test suite and included
it in the tarball.  These test whether everything is compiled
correctly, as well as a set of tests to look at how well the compiler
is optimizing these sorts of codes.  If anyone is interested, the code
is at

http://superbeast.ucsd.edu/~landry/FTensor

I don't know what kind of format is preferred for the test suite.  I'd
be happy to modify the test so that it outputs the results in a
suitable form.

In any case, thanks for the great compiler.

Walter Landry
wlandry@ucsd.edu

Re: Successful Compilation

[Janis Johnson]

On Mon, Mar 25, 2002 at 03:32:56PM -0800, Walter Landry wrote:
> Greetings,
> 
> First of all, I would like to thank each and every one of you.  I've
> constructed a tensor library using a number of C++ template tricks.
> Until recently, gcc would not compile it (PR 2494).  I was stuck using
> proprietary compilers, causing me no end of grief.  A week ago, I
> downloaded gcc-3_1-branch and, lo and behold, it now works.  Huzzah!
> It still gives a warning about implicit typenames, but I can live with
> that.  Since I've tested this library on more compilers than you can
> shake a stick at, I think that is a bug in gcc.
> 
> In any case, I noticed that there is a list of libraries that GCC 3.1
> is being tested against.  One of the implicit goals seems to be good
> template support.  Since my library seems to stress the template
> support more than the other libraries (as I said, gcc only recently
> started compiling it), I thought it might be useful to the gcc team as
> a test.
> 
> I have already written a fairly comprehensive test suite and included
> it in the tarball.  These test whether everything is compiled
> correctly, as well as a set of tests to look at how well the compiler
> is optimizing these sorts of codes.  If anyone is interested, the code
> is at
> 
> http://superbeast.ucsd.edu/~landry/FTensor

The link to the newer version is to file://something.  If that's the one
you'd like people to try, let us know when the link is fixed.
 
> I don't know what kind of format is preferred for the test suite.  I'd
> be happy to modify the test so that it outputs the results in a
> suitable form.

See http://gcc.gnu.org/gcc-3.0/lapack-guide.html for an example of
useful instructions for trying out your library.  Please explain how
to compile with a specified set of compilation options; building with
different sets of optimization flags is a good way to flush out
compiler bugs.

I'm pounding on the GCC 3.1 prerelease on ia64-linux and look forward to
trying out your library.

Janis

Re: Successful Compilation

[Walter Landry]

Janis Johnson <janis187@us.ibm.com> wrote:
> On Mon, Mar 25, 2002 at 03:32:56PM -0800, Walter Landry wrote:
> > http://superbeast.ucsd.edu/~landry/FTensor
> 
> The link to the newer version is to file://something.  If that's the one
> you'd like people to try, let us know when the link is fixed.

Argh.  I've fixed it.  Sorry for the mess.  I shouldn't have fiddled
with the page without testing it.  The older version is definitely not
what you want.

> > I don't know what kind of format is preferred for the test suite.  I'd
> > be happy to modify the test so that it outputs the results in a
> > suitable form.
> 
> See http://gcc.gnu.org/gcc-3.0/lapack-guide.html for an example of
> useful instructions for trying out your library.  Please explain how
> to compile with a specified set of compilation options; building with
> different sets of optimization flags is a good way to flush out
> compiler bugs.

There is a simple Makefile in the testing and testing2 directories.
I'll add a README in those directories to make it clear.  If you give
me a few hours, I'll fix the tests so that they print out "passed" or
"failed".  Right now, the output is difficult to grep by hand.

Regards,
Walter Landry
wlandry@ucsd.edu

Re: Successful Compilation

[Walter Landry]

Walter Landry <wlandry@ucsd.edu> wrote:
> Janis Johnson <janis187@us.ibm.com> wrote:
> > On Mon, Mar 25, 2002 at 03:32:56PM -0800, Walter Landry wrote:
> > > I don't know what kind of format is preferred for the test suite.  I'd
> > > be happy to modify the test so that it outputs the results in a
> > > suitable form.
> > 
> > See http://gcc.gnu.org/gcc-3.0/lapack-guide.html for an example of
> > useful instructions for trying out your library.  Please explain how
> > to compile with a specified set of compilation options; building with
> > different sets of optimization flags is a good way to flush out
> > compiler bugs.
> 
> There is a simple Makefile in the testing and testing2 directories.
> I'll add a README in those directories to make it clear.  If you give
> me a few hours, I'll fix the tests so that they print out "passed" or
> "failed".  Right now, the output is difficult to grep by hand.

I've moved all of the tests into a directory named "tests".  There are
some conformance tests which print out "pass" or "fail".  Nothing
should fail.  There are also some speed tests to see how well the
compiler optimizes the code.  These are explained in more detail in
tests/README.

Let me know if there is anything else I should do.

Regards,
Walter Landry
wlandry@ucsd.edu

Re: Successful Compilation

[mike stump]

> Date: Mon, 25 Mar 2002 15:32:56 -0800 (PST)
> To: gcc@gcc.gnu.org
> From: Walter Landry <wlandry@ucsd.edu>

> In any case, I noticed that there is a list of libraries that GCC
> 3.1 is being tested against.  One of the implicit goals seems to be
> good template support.  Since my library seems to stress the
> template support more than the other libraries (as I said, gcc only
> recently started compiling it), I thought it might be useful to the
> gcc team as a test.

Bear in mind, if you would like, you can help contribute to the effort
by just downloading snapshots every now and then and running your
testsuite and emailing the results to gcc testresults mailing list.
And if testing shows up regressions in the compiler or runtime
library, to file bug reports promptly noting when last it worked, and
when exactly it failed.

> I don't know what kind of format is preferred for the test suite.  I'd
> be happy to modify the test so that it outputs the results in a
> suitable form.

PASS: unique name of testcase
FAIL: unique name of testcase

and for the names of the testcases to be stable, and for the total
number to remain relatively constant (monotonically increasing over
the years of course).

Re: Successful Compilation

[Walter Landry]

mike stump <mrs@windriver.com> wrote:
> Bear in mind, if you would like, you can help contribute to the effort
> by just downloading snapshots every now and then and running your
> testsuite and emailing the results to gcc testresults mailing list.
> And if testing shows up regressions in the compiler or runtime
> library, to file bug reports promptly noting when last it worked, and
> when exactly it failed.

I'm hesitant to submit results to the testresults list for software no
one has never heard of.  In any case, I'd like the test suite to be
useful to others.  That will make it easier for anyone hacking on gcc
or any other compiler to see what's going on.  The only real problem
right now is the spurious implicit typename warnings, which seems to
be covered by PR 5507.

> > I don't know what kind of format is preferred for the test suite.  I'd
> > be happy to modify the test so that it outputs the results in a
> > suitable form.
> 
> PASS: unique name of testcase
> FAIL: unique name of testcase
> 
> and for the names of the testcases to be stable, and for the total
> number to remain relatively constant (monotonically increasing over
> the years of course).

I've set up a new version (1.1-patch-10) such that all 5000+ tests have
unique names.  A lot of these tests look at similar code
(e.g. replacing + with -), so the actual number of tests of the
compiler is much less.  If there is more that should be done, let me
know.

Regards,
Walter Landry
wlandry@ucsd.edu

Re: Successful Compilation

[Janis Johnson]

On Wed, Mar 27, 2002 at 03:16:13PM -0800, Walter Landry wrote:
> mike stump <mrs@windriver.com> wrote:
> > Bear in mind, if you would like, you can help contribute to the effort
> > by just downloading snapshots every now and then and running your
> > testsuite and emailing the results to gcc testresults mailing list.
> > And if testing shows up regressions in the compiler or runtime
> > library, to file bug reports promptly noting when last it worked, and
> > when exactly it failed.
> 
> I'm hesitant to submit results to the testresults list for software no
> one has never heard of.  In any case, I'd like the test suite to be
> useful to others.  That will make it easier for anyone hacking on gcc
> or any other compiler to see what's going on.  The only real problem
> right now is the spurious implicit typename warnings, which seems to
> be covered by PR 5507.

Walter, I think that you and Mike are talking about different things
here.  You're talking about the test results for FTensor, which you
would like to have used as part of GCC integration testing, while Mike
is talking about the normal GCC testsuite.

Mike has a good point that all GCC users can help out by building
snapshots occasionally, submitting test results, building their own
favorite software packages, and reporting bugs.  This is particularly
useful in the last couple of months before a release when there are a
lot of GCC contributors ready to fix bugs.

Walter is proposing another package for integration testing.  It makes
extensive use of templates in a way that stresses the C++ compiler, and
it comes with tests whose results are easy to interpret.  Those make it
worthwhile to try out.  A disadvantage is that it takes a very long time
to compile, at least on my Itanium system.

> > > I don't know what kind of format is preferred for the test suite.  I'd
> > > be happy to modify the test so that it outputs the results in a
> > > suitable form.
> > 
> > PASS: unique name of testcase
> > FAIL: unique name of testcase
> > 
> > and for the names of the testcases to be stable, and for the total
> > number to remain relatively constant (monotonically increasing over
> > the years of course).

This is true for tests in the GCC test suite.  A similar format would
make the FTensor test results easy to evaluate automatically.
 
> I've set up a new version (1.1-patch-10) such that all 5000+ tests have
> unique names.  A lot of these tests look at similar code
> (e.g. replacing + with -), so the actual number of tests of the
> compiler is much less.  If there is more that should be done, let me
> know.

Great!  I'm building the tests for 1.1--patch-5 right now and was going
to recommend that you break down the tests somewhat.  It would be nice
to be able to specify subsets of them, to allow doing some of them as
part of our local nightly testing.  I'd also like to see the flags in
the Makefile broken apart so that it would be simple to change the
optimization options without needing to specify the rest of them, e.g.,

CXXOPTS = -g -O2
CXXFLAGS = -ftemplate-depth-100 -Drestrict= -w -DFTENSOR_DEBUG $(CXXOPTS)

Janis

Re: Successful Compilation

[Walter Landry]

Janis Johnson <janis187@us.ibm.com> wrote:
> Walter, I think that you and Mike are talking about different things
> here.  You're talking about the test results for FTensor, which you
> would like to have used as part of GCC integration testing, while Mike
> is talking about the normal GCC testsuite.
> 
> Mike has a good point that all GCC users can help out by building
> snapshots occasionally, submitting test results, building their own
> favorite software packages, and reporting bugs.  This is particularly
> useful in the last couple of months before a release when there are a
> lot of GCC contributors ready to fix bugs.

My main platform is 686 Intel.  It seems that there are already plenty
of people submitting test reports for that.  However, I also have
access to a Solaris 8 machine and an AIX 5L machine.  There seem to be
other people submitting test results for Solaris 8, so I might just
submit results for AIX.  In any case, don't worry.  I won't stop
submitting bugs.  Especially if they break my pet project.  However,
my time is limited.

> Walter is proposing another package for integration testing.  It makes
> extensive use of templates in a way that stresses the C++ compiler, and
> it comes with tests whose results are easy to interpret.  Those make it
> worthwhile to try out.  A disadvantage is that it takes a very long time
> to compile, at least on my Itanium system.

Are you talking mostly about the conformance tests?  Does it take an
excessive time only when compiling it with optimizations, or is it
always true?  It takes me about 15 minutes to build with no
optimizations on my Pentium II 366 laptop.  I can do a lot to speed up
things if optimization is the problem, but not much if the baseline is
slow.

The speed tests, on the other hand, can't really be sped up at all.
With optimizations, they only take 4-5 minutes on my laptop, so it
shouldn't be too much of a problem.

> Great!  I'm building the tests for 1.1--patch-5 right now and was going
> to recommend that you break down the tests somewhat.  It would be nice
> to be able to specify subsets of them, to allow doing some of them as
> part of our local nightly testing.

I can actually break up the tests quite a bit.  The gcc crowd might
only be interested in the tests in test_T0, test_T1, test_T2,
test_T2s, and test_T3as.  I think those tests alone cover almost every
technique I use.  The other tests are there to make sure I implemented
everything correctly.  It doesn't really stretch the compiler any
differently, though.

> I'd also like to see the flags in
> the Makefile broken apart so that it would be simple to change the
> optimization options without needing to specify the rest of them, e.g.,
> 
> CXXOPTS = -g -O2
> CXXFLAGS = -ftemplate-depth-100 -Drestrict= -w -DFTENSOR_DEBUG $(CXXOPTS)

No problem.  I'll fold that into the next release.

Regards,
Walter Landry
wlandry@ucsd.edu