This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils 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: Results for binutils (CVS main branch Mon Feb 18 05:56:31 UTC 2002) testsuite on sparc-unknown-linux-gnu


On Mon, Feb 18, 2002 at 07:14:17PM -0500, Daniel Jacobowitz wrote:
> On Mon, Feb 18, 2002 at 09:17:10PM +0100, Christian J?nsson wrote:
> > On Mon, Feb 18, 2002 at 02:15:32PM -0500, Daniel Jacobowitz wrote:
> > > On Mon, Feb 18, 2002 at 07:36:46PM +0100, Christian J?nsson wrote:
> > > > This was on a Debian Woody (test release) sun4m system using
> > > > 
> > > > binutils       2.11.92.0.12.3-6
> > > > dejagnu        1.4-4
> > > > gcc-3.0        3.0.3-1
> > > > libc6          2.2.5-3
> > > > 
> > > > /ChJ
> > > > LAST_UPDATED: Mon Feb 18 05:56:31 UTC 2002
> > 
> > Note that this was compiled as a part of a gcc-3.1 bootstrap...
> >  
> > > I think I committed the fix for the visibility stuff (which I appear to
> > > have botched) just after that time.  No, it was just before...
> > 
> > The binutils directory has a time stamp of
> > 
> > Mon Feb 18 05:57:51 UTC 2002
> > 
> > which is about minute later on (it perhaps takes a minute to update
> > binutils)...
> 
> Your script is a little confused.  Are you on a different UTC than I
> am?

uhm, how could we ever know? i run the gcc update script in the gcc
sources and then change dir into the binutils sources and do a cvs -q
followd by 'LANG=C date > LAST_UPDATED; LANG=C TZ=C date >>
LAST_UPDATED'...

> I'd actually committed something that didn't compile, just fixed.  If
> you'd actually updated at the time you list above, the entire set of
> visibility tests would have been ERRORs.

There are a bunch of ERROR and WARNING messages, I just wrote the gcc
list yesterday about the idea of having the test summary script in the
gcc sources actually output the WARNING and ERROR results of a test
suite run. Let's see what happens.

> 
> > 21,22c21,22
> > < visibility_checkvarptr () == 0
> > < main_visibility_checkvar () == 0
> > ---
> > > visibility_checkvarptr () == 1
> > > main_visibility_checkvar () == 1
> > child process exited abnormally
> > FAIL: visibility (hidden_weak) (PIC main)
> 
> Please try this again.  If it persists, something is seriously wrong. 
> I don't see these.
> 
> > > > FAIL: S-records
> > > > FAIL: S-records with constructors
> > > 
> > > What's in your logs for this one?  You seemed to have a different issue
> > > from Jakub.
> > 
> > /share1/gcc-dev/gcc/objdir/gcc/xgcc -B/share1/gcc-dev/gcc/objdir/gcc/ -B/usr/local/sparc-linux/bin/ -B/usr/local/sparc-linux/lib/ -isystem /usr/local/sparc-linux/include -L/share1/gcc-dev/gcc/objdir/ld -B/share1/gcc-dev/gcc/objdir/ld/tmpdir/gas/ -I/share1/gcc-dev/gcc/ld/testsuite/ld-srec -g  -fPIC -c /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr1.c -o tmpdir/sr1.o
> > /share1/gcc-dev/gcc/objdir/gcc/xgcc -B/share1/gcc-dev/gcc/objdir/gcc/ -B/usr/local/sparc-linux/bin/ -B/usr/local/sparc-linux/lib/ -isystem /usr/local/sparc-linux/include -L/share1/gcc-dev/gcc/objdir/ld -B/share1/gcc-dev/gcc/objdir/ld/tmpdir/gas/ -I/share1/gcc-dev/gcc/ld/testsuite/ld-srec -g  -fPIC -c /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr2.c -o tmpdir/sr2.o
> > /share1/gcc-dev/gcc/objdir/ld/ld-new  -o tmpdir/sr1  -Ttext 0x1000 tmpdir/sr1.o tmpdir/sr2.o
> > /share1/gcc-dev/gcc/objdir/ld/ld-new  -o tmpdir/sr2.sr  -Ttext 0x1000 --oformat srec tmpdir/sr1.o tmpdir/sr2.o
> > tmpdir/sr1.o: In function `main':
> > /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr1.c:16: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> > /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr1.c:17: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> > tmpdir/sr2.o: In function `fn1':
> > /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr2.c:9: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> > /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr2.c:10: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> > tmpdir/sr2.o: In function `fn2':
> > /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr2.c:16: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> > tmpdir/sr2.o:/share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr2.c:17: more undefined references to `_GLOBAL_OFFSET_TABLE_' follow
> > FAIL: S-records
> > /share1/gcc-dev/gcc/objdir/gcc/g++ -B/share1/gcc-dev/gcc/objdir/gcc/ -nostdinc++ -nostdinc++ -I/share1/gcc-dev/gcc/objdir/sparc-linux/libstdc++-v3/include/sparc-linux -I/share1/gcc-dev/gcc/objdir/sparc-linux/libstdc++-v3/include -I/share1/gcc-dev/gcc/libstdc++-v3/libsupc++ -I/share1/gcc-dev/gcc/libstdc++-v3/libio -I/share1/gcc-dev/gcc/libstdc++-v3/include/backward -I/share1/gcc-dev/gcc/libstdc++-v3/testsuite -L/share1/gcc-dev/gcc/objdir/sparc-linux/libstdc++-v3/src -L/share1/gcc-dev/gcc/objdir/sparc-linux/libstdc++-v3/src/.libs -B/usr/local/sparc-linux/bin/ -B/usr/local/sparc-linux/lib/ -isystem /usr/local/sparc-linux/include -L/share1/gcc-dev/gcc/objdir/ld -g -O2 -fgnu-linker -fno-exceptions -B/share1/gcc-dev/gcc/objdir/ld/tmpdir/gas/ -I/share1/gcc-dev/gcc/ld/testsuite/ld-srec -g  -fPIC -c /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr3.cc -o tmpdir/sr3.o
> > /share1/gcc-dev/gcc/objdir/ld/ld-new  -o tmpdir/sr1  -Ttext 0x1000 tmpdir/sr3.o
> > /share1/gcc-dev/gcc/objdir/ld/ld-new  -o tmpdir/sr2.sr  -Ttext 0x1000 --oformat srec tmpdir/sr3.o
> > tmpdir/sr3.o: In function `main':
> > /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr3.cc:24: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> > /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr3.cc:25: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> > tmpdir/sr3.o: In function `Foo::init_foo()':
> > /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr3.cc:87: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> > /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr3.cc:88: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> > tmpdir/sr3.o: In function `Foo::Foo()':
> > /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr3.cc:92: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> > tmpdir/sr3.o:/share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr3.cc:93: more undefined references to `_GLOBAL_OFFSET_TABLE_' follow
> > FAIL: S-records with constructors
> 
> I don't see these, either, which is quite odd.
> 
> What exactly is your configure command?

It's stated further down in the first e-mail of this thread, 

configure flags: --host=sparc-linux --enable-shared --enable-threads=posix

> > /share1/gcc-dev/gcc/objdir/gcc/xgcc -B/share1/gcc-dev/gcc/objdir/gcc/ -B/usr/local/sparc-linux/bin/ -B/usr/local/sparc-linux/lib/ -isystem /usr/local/sparc-linux/include -L/share1/gcc-dev/gcc/objdir/ld -S -g -B/share1/gcc-dev/gcc/objdir/ld/tmpdir/gas/ -I/share1/gcc-dev/gcc/ld/testsuite/ld-elfvers -g  -fpic -c /share1/gcc-dev/gcc/ld/testsuite/ld-elfvers/vers3.c -o tmpdir/vers3.s
> 
> xgcc is gcc 3.1 there, I assume?  Binutils is what, 2.12 branch?  CVS
> head?

Like I said in the previous e-mail, *this* was built and run as a part
of a gcc-3.1 bootstrap. And, in the subject and a bit to the end in
the first e-mail of this thread, it's a main branch, not a from the
2.12 branch. I'd also like to add here that perhaps a versioning
handling like the gcc sources is appropriate. I mean a version like
something like this:

binutils 2.13 20020218 (experimental) for the main cvs branch, daily
date bump as it has today

binutils 2.12 20020218 (prerelease) for a 2,12 prerelease cvs branch,
daily date bumps here as well.

binutils 2.12 (release) for an actual 2,12 release

Furthermore, the test suite outputs could contain these outputs,
similar to the gcc test suite outputs.

And, we could make use of the gcc test summary and warning summary
scripts, perhaps a little tweaking could be done to those scripts to
catch the version information and outout it instead of the string gcc...

Perhapas we could modify the binutils test suite scripts to generate
output that fits a "common" test summary script. It's a good thing
(TM) I guess, but I am not able to do it myself, I need help to do so.

> > /share1/gcc-dev/gcc/objdir/ld/../gas/as-new   -o tmpdir/vers3.o tmpdir/vers3.s
> > /share1/gcc-dev/gcc/objdir/ld/ld-new -m elf32_sparc  -o tmpdir/vers3 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o ../gcc/crtbegin.o  tmpdir/vers3.o tmpdir/vers1.so  ../gcc/libgcc.a -L/usr/lib -lc ../gcc/libgcc.a ../gcc/crtend.o /usr/lib/crtn.o
> > tmpdir/vers3.o: In function `main':
> > /share1/gcc-dev/gcc/ld/testsuite/ld-elfvers/vers3.c:11: relocation truncated to fit: R_SPARC_13 .rodata
> > FAIL: vers3
> > /share1/gcc-dev/gcc/objdir/gcc/xgcc -B/share1/gcc-dev/gcc/objdir/gcc/ -B/usr/local/sparc-linux/bin/ -B/usr/local/sparc-linux/lib/ -isystem /usr/local/sparc-linux/include -L/share1/gcc-dev/gcc/objdir/ld -S -g -B/share1/gcc-dev/gcc/objdir/ld/tmpdir/gas/ -I/share1/gcc-dev/gcc/ld/testsuite/ld-elfvers -g  -fpic -c /share1/gcc-dev/gcc/ld/testsuite/ld-elfvers/vers4.c -o tmpdir/vers4.s
> > /share1/gcc-dev/gcc/objdir/ld/../gas/as-new   -o tmpdir/vers4.o tmpdir/vers4.s
> > /share1/gcc-dev/gcc/objdir/ld/ld-new -m elf32_sparc  -o tmpdir/vers4 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o ../gcc/crtbegin.o  tmpdir/vers4.o   ../gcc/libgcc.a -L/usr/lib -lc ../gcc/libgcc.a ../gcc/crtend.o /usr/lib/crtn.o
> > tmpdir/vers4.o: In function `main':
> > /share1/gcc-dev/gcc/ld/testsuite/ld-elfvers/vers4.c:29: relocation truncated to fit: R_SPARC_13 .rodata
> > FAIL: vers4
> > /share1/gcc-dev/gcc/objdir/gcc/xgcc -B/share1/gcc-dev/gcc/objdir/gcc/ -B/usr/local/sparc-linux/bin/ -B/usr/local/sparc-linux/lib/ -isystem /usr/local/sparc-linux/include -L/share1/gcc-dev/gcc/objdir/ld -S -g -B/share1/gcc-dev/gcc/objdir/ld/tmpdir/gas/ -I/share1/gcc-dev/gcc/ld/testsuite/ld-elfvers -g  -fpic -c /share1/gcc-dev/gcc/ld/testsuite/ld-elfvers/vers4.c -o tmpdir/vers4a.s
> > /share1/gcc-dev/gcc/objdir/ld/../gas/as-new   -o tmpdir/vers4a.o tmpdir/vers4a.s
> > /share1/gcc-dev/gcc/objdir/ld/ld-new -m elf32_sparc  -o tmpdir/vers4a -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o ../gcc/crtbegin.o -export-dynamic tmpdir/vers4a.o   ../gcc/libgcc.a -L/usr/lib -lc ../gcc/libgcc.a ../gcc/crtend.o /usr/lib/crtn.o
> > tmpdir/vers4a.o: In function `main':
> > /share1/gcc-dev/gcc/ld/testsuite/ld-elfvers/vers4.c:29: relocation truncated to fit: R_SPARC_13 .rodata
> > FAIL: vers4a
> 
> I've no idea at all where this is coming from.

OK.

> > So, that's that. Why don't I test build binutils 2.12 branch usinf
> > gcc-3.0.3 and submit those results and we'll look into that?
> 
> Please do.

Posted. One odd thing though, whenever I run the testsuite with
gcc-3.0.3 to compile the tests, I get cdtest failures...

/ChJ


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