This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] fixes to consistency.vlad/vlad.exp


On Fri, Aug 23, 2002 at 09:11:18PM -0400, Phil Edwards wrote:
> On Fri, Aug 23, 2002 at 05:25:50PM -0700, Janis Johnson wrote:
> > C++ tests were built
> > using "gcc -x c++", which caused failures for tests with vtables, so now
> > they are built with g++ instead.
> 
> That seems worrying.

Tests class-*-and-virtual.cpp in consistency.vlad/layout all fail when
built with "gcc -x c++" rather than with "g++".

When built with gcc:

  /tmp/ccGpUaWO.o(.gnu.linkonce.d._ZTI3sss+0x0): undefined reference to
  `vtable for __cxxabiv1::__class_type_info'

When built with g++:

  laptop% nm a.out | fgrep class_type_info
           U _ZTVN10__cxxabiv117__class_type_infoE
  laptop% nm libstdc++.so | fgrep _ZTVN10__cxxabiv117__class_type_infoE
  0005fea0 W _ZTVN10__cxxabiv117__class_type_infoE

We apparently need a set of tests that check that basic C++ runtime
support is available outside of libstdc++.

I'll change my patch for vlad.exp back to use gcc rather than g++.
 
> 
> > - how to store baseline results; can they be stored as gzipped tarballs
> >   to save space?
> 
> How big are they?  I recommend using bzip2 instead of gzip.

laptop% du -b i686*
1132544 i686-pc-linux-gnu-results
15360   i686-pc-linux-gnu-results.tar.bz2
36864   i686-pc-linux-gnu-results.tar.gz
> 
> If we decide to store binary files in the repository, we will be unable
> to look at diffs between revisions.  Or do pretty much anything between
> revisions, other than "get an older one."  This may be a fine thing to do;
> I'm just bringing it to your attention.

I don't like the idea of using binary files, either.  For now I'd like
to get the consistency.vlad tests working, and continue to ponder what
might be a good way to store the results.  Ideally we'll have results
available for lots of targets, so size will be an issue.  Perhaps they
could be kept separately somewhere.

Janis


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]