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: cross binutils 2.12 test summary


Daniel Jacobowitz wrote:
> 
> On Thu, Feb 21, 2002 at 06:07:57AM -0600, Joel Sherrill wrote:
> >
> > Hi,
> >
> > After the comments I received about generating a lot of
> > email people suggested filtering the logs down, having
> > a testresults mailing list, testr results web page, etc.
> > The bottom line was that no one wanted to wade through
> > all of it.  So this email is the result.  I filtered
> > the build results down to a single not so long email. :)
> 
> Thanks for all your work on this!

It was more than "no problem" but something that needed to
be done. :)
 
FYI my 32 yr old brother-in-law passed away unexpectedly for 
no apparent reason yesterday.  :( I expect to be randomly 
available for the next few days. :(

> > Source: binutils 2.12 CVS checked out around Feb 15
> > Host: Redhat 7.2
> > 46 Targets attempted:
> >
> >     a29k-coff a29k-rtems arc-elf arm-elf arm-rtems avr-elf
> >     c30-coff c54x-coff d10v-elf d30v-elf fr30-elf
> >     h8300-coff h8300-rtems hppa1.1-proelf
> >     hppa1.1-rtems i386-elf i386-rtems i960-coff i960-elf i960-rtems
> >     m32r-elf m68hc11-elf m68hc12-elf m68k-coff m68k-elf
> >     m68k-rtems m68k-rtemself mcore-elf
> >     mips64orion-elf mips64orion-rtems mips-elf mips-rtems mn10200-elf
> >     mn10300-elf or32-rtems pdp11-aout
> >     powerpc-eabi powerpc-rtems sh-coff sh-elf sh-hms
> >     sh-rtems sh-rtemself sparc-elf sparc-rtems v850-elf
> >
> > I have a few that did not successfully build:
> >
> >  c30-coff - did not configure successfully
> >     What is the target for TI C3x/C4x DSPs?  I can't find one. :(
> 
> Try tic30-coff/tic54x-coff?

tic30-coff did not work.  I didn't have time for the other.
Perhaps Timothy Wall has a suggestion.

> >  sh-hms - previously reported
> 
> I think sh-hms is just a configury problem.  No one has commented, but
> my guess is that it should really be an alias for sh-coff.

That's what I would guess.  For sure that's all sh-rtems is.

> > Here are all the test failures for those targets
> >
> > a29k-rtems/binutils/binutils.sum:FAIL: objcopy (simple copy)
> > arc-elf/ld/ld.sum:FAIL: ld-discard/extern
> > arc-elf/ld/ld.sum:FAIL: ld-discard/start
> > arc-elf/ld/ld.sum:FAIL: ld-discard/static
> > avr-elf/gas/testsuite/gas.sum:FAIL: elf ehopt0
> > avr-elf/gas/testsuite/gas.sum:FAIL: strings
> > avr-elf/gas/testsuite/gas.sum:FAIL: vtable inherit0
> > avr-elf/gas/testsuite/gas.sum:FAIL: vtable entry1
> > d10v-elf/gas/testsuite/gas.sum:FAIL: vtable inherit0
> > d30v-elf/gas/testsuite/gas.sum:FAIL: D30V debug (-g) test
> > d30v-elf/gas/testsuite/gas.sum:FAIL: D30V serial
> > d30v-elf/gas/testsuite/gas.sum:FAIL: D30V serial2
> > d30v-elf/gas/testsuite/gas.sum:FAIL: D30V serial2O
> > d30v-elf/gas/testsuite/gas.sum:FAIL: elf ehopt0
> > fr30-elf/ld/ld.sum:FAIL: ld-discard/extern
> > h8300-rtems/binutils/binutils.sum:FAIL: objcopy (simple copy)
> > hppa1.1-proelf/gas/testsuite/gas.sum:FAIL: Check for error(s) in branch
> > length
> > i960-elf/ld/ld.sum:FAIL: check sections 1
> > i960-elf/ld/ld.sum:FAIL: check sections 2
> > i960-elf/ld/ld.sum:FAIL: ld-discard/extern
> > i960-elf/ld/ld.sum:FAIL: ld-discard/start
> > i960-elf/ld/ld.sum:FAIL: ld-discard/static
> > i960-elf/ld/ld.sum:FAIL: DEFINED (PRMS 5699)
> > i960-elf/ld/ld.sum:FAIL: PHDRS
> > i960-elf/ld/ld.sum:FAIL: script
> > i960-elf/ld/ld.sum:FAIL: MRI script
> > i960-elf/ld/ld.sum:FAIL: SIZEOF
> > i960-elf/ld/ld.sum:FAIL: weak symbols
> > i960-elf/ld/ld.sum:FAIL: Preserve default . = 0
> > i960-elf/ld/ld.sum:FAIL: Preserve explicit . = 0
> > i960-elf/ld/ld.sum:FAIL: weak undefined symbols
> > i960-rtems/binutils/binutils.sum:FAIL: objcopy (simple copy)
> > m68hc11-elf/gas/testsuite/gas.sum:FAIL: Motorola Assembly Language Input
> > Standar
> > d
> > m68hc11-elf/gas/testsuite/gas.sum:FAIL: MRI constants
> > m68hc11-elf/gas/testsuite/gas.sum:FAIL: MRI immediate constants
> > m68hc11-elf/gas/testsuite/gas.sum:FAIL: MRI structured for
> > m68hc11-elf/gas/testsuite/gas.sum:FAIL: MRI structured if
> > m68hc11-elf/gas/testsuite/gas.sum:FAIL: MRI structured repeat
> > m68hc11-elf/gas/testsuite/gas.sum:FAIL: MRI structured while
> > m68hc11-elf/gas/testsuite/gas.sum:FAIL: MRI moveml
> > m68hc12-elf/gas/testsuite/gas.sum:FAIL: Motorola Assembly Language Input
> > Standar
> > d
> > m68hc12-elf/gas/testsuite/gas.sum:FAIL: MRI constants
> > m68hc12-elf/gas/testsuite/gas.sum:FAIL: MRI immediate constants
> > m68hc12-elf/gas/testsuite/gas.sum:FAIL: MRI structured for
> > m68hc12-elf/gas/testsuite/gas.sum:FAIL: MRI structured if
> > m68hc12-elf/gas/testsuite/gas.sum:FAIL: MRI structured repeat
> > m68hc12-elf/gas/testsuite/gas.sum:FAIL: MRI structured while
> > m68hc12-elf/gas/testsuite/gas.sum:FAIL: MRI moveml
> > m68k-coff/gas/testsuite/gas.sum:FAIL: pcrel
> > m68k-coff/gas/testsuite/gas.sum:FAIL: MRI moveml
> > m68k-elf/ld/ld.sum:FAIL: ld-discard/extern
> > mcore-elf/gas/testsuite/gas.sum:FAIL: strings
> > mcore-elf/gas/testsuite/gas.sum:FAIL: allinsn
> > mips64orion-rtems/gas/testsuite/gas.sum:FAIL: MIPS jal
> > mips-rtems/gas/testsuite/gas.sum:FAIL: MIPS jal
> > mn10200-elf/gas/testsuite/gas.sum:FAIL: vtable inherit0
> > mn10200-elf/gas/testsuite/gas.sum:FAIL: vtable entry1
> > or32-rtems/binutils/binutils.sum:FAIL: objcopy (simple copy)
> > powerpc-rtems/ld/ld.sum:FAIL: S-records
> > powerpc-rtems/ld/ld.sum:FAIL: S-records with constructors
> > sh-rtems/binutils/binutils.sum:FAIL: strip
> >
> > One thing I noticed is that XXX-rtems is a simple wrapper for
> > XXX-object_format and sometimes the rtems target reports a failure
> > that the comparable simple target doesn't.  sh-rtems does not
> > match sh-coff, powerpc-rtems does not match any powerpc-eabi
> > or -elf errors.  Any ideas?
> >
> > This should be more helpful. :)
> 
> I'd guess configury again.  I don't see why for (for instance)
> powerpc-rtems; diffing generated headers in two build directories might
> show it.

Is there any testsuite configuery which might be not setup properly?
Perhaps not matching *-rtems correctly.

> As far as the rest of these failures go, I'm not planning to hold up
> release for any of them; what I would prefer to do is to pursue them
> for 2.12.1 or 2.13.  However, if anyone manages to fix some of them
> before we are quite ready, that'd be good :)  None of them seem to be
> completely dysfunctional.

Given all the gcc build and test failures I have seen, I thought these
results were fantastic.

> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985


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