public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Exhaustive simulator testing
@ 2002-09-26 14:51 Zack Weinberg
  2002-09-27  3:11 ` Richard Earnshaw
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Zack Weinberg @ 2002-09-26 14:51 UTC (permalink / raw)
  To: gcc

Mostly to see what would happen, I wrote a script that built and
tested the combined tree for every last target in the matrix I posted
yesterday as part of the simtest-howto rewrite.

Just over half of them fail to build for various reasons:

d10v-elf        - not supported by GCC
mn10200-elf     - not supported by GCC (obsoleted target)

Did the d10v back end just never get checked in?  It isn't mentioned
anywhere in gcc/ChangeLog, but I'm pretty sure I've seen reference to
its existing.

d30v-elf        - not supported by GDB
fr30-elf        - not supported by GDB
i960-coff       - not supported by GDB

It Would Be Nice if it were possible to build the simulator without
also building GDB.  It Would Be Really Nice if you didn't have to
have GDB's sources in the tree at all.

m32r-elf        - ICE during build

newlib/libc/stdlib/dtoa.c: In function `_dtoa_r':
newlib/libc/stdlib/dtoa.c:854: internal compiler error: RTL flag check: 
   CONSTANT_POOL_ADDRESS_P used with unexpected rtx code `const' in
   addr24_operand, at config/m32r/m32r.c:603

m6811-elf       - libgloss bug

libgloss/m68hc11/syscalls.c:53: error: conflicting types for `sbrk'
newlib/libc/include/sys/unistd.h:97: error: previous declaration of `sbrk'

mcore-elf       - ICE during build

libgcc2.c: In function `__lshrdi3':
libgcc2.c:265: error: Too many outgoing branch edges from bb 1
libgcc2.c:265: internal compiler error: verify_flow_info failed

mn10300-elf     - GAS barfs during build

_muldi3.s: Assembler messages:
_muldi3.s:829: Error: can't resolve `.Letext0' {.text section} 
    - `.Ltext0' {.text section}

sparclite-elf   - hits #error in crtstuff.c during build

<command line>:12:10: warning: "cpu" re-asserted
<command line>:13:14: warning: "machine" re-asserted
crtstuff.c:415:2: #error "What are you doing with crtstuff.c, then?"
crtstuff.c:183: warning: `__DTOR_LIST__' defined but not used
crtstuff.c:195: warning: `__EH_FRAME_BEGIN__' defined but not used

The rest do build, but the test suites are in varying degrees of
shape.  Here's a matrix - I foolishly forgot to check out all the
language runtime libraries, so I only have meaningful results for C.
All these targets successfully built the C++, ObjC, and Fortran front
ends.  (I'm not about to try to nail down which of these targets
support Java and Ada.)

arm-elf                  pass  fail  xpass xfail  unres unsup untest
        binutils           31     1
        gas                63
        ld                 29                  3
        newlib              5     1
        gdb              6832   291           51     30    11      9
        gcc             20211    26      1    63     42   150

h8300-hms                pass  fail  xpass xfail  unres unsup untest
        binutils           21     1                                4
        gas                81                  3
        ld                 14     3                   3
        newlib                    6
        gdb               947  2150           34    197     9      9
        gcc             11039  4593      2    54   4411   159

mips-elf                 pass  fail  xpass xfail  unres unsup untest
        binutils           30                  2
        gas               123     5            1
        ld                 42     1      4     1
        newlib              5     1
        gdb              6757   370           51     50    11      9
        gcc             20165    67           86     52   148

mips64-elf               pass  fail  xpass xfail  unres unsup untest
        binutils           30                  2
        gas               123     5            1
        ld                 41     2      4     1
        newlib                    6
        gdb              4483  1737      2   140     86    11      9
        gcc             20162    65           92     53   147

powerpc-eabisim          pass  fail  xpass xfail  unres unsup untest
        binutils           31     1
        gas                27
        ld                 24            2     1
        newlib                    6
        gdb              6446   291      7    58     30    11      9
        gcc             20258    22           62     42   137

sh-hms                   pass  fail  xpass xfail  unres unsup untest
        binutils           24     2
        gas                28     2                         2
        ld                 14     5      2            3            1
        newlib              4     2
        gdb              6174   436      2   147     32    11      9
        gcc             20151    30           62     11   156

sparc64-elf              pass  fail  xpass xfail  unres unsup untest
        binutils           25                                      7
        gas                49                  2
        ld                 19                        13
        newlib                    6
        gdb              1998  2039           40    133     7      9
        gcc               660 14962     33    20   4496   142

v850-elf                 pass  fail  xpass xfail  unres unsup untest
        binutils           31                  1
        gas                47
        ld                 29                  3
        newlib              5     1
        gdb              6695   285     90    59     30    11      9
        gcc             20187    56      1    61     48   151

zw

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Exhaustive simulator testing
  2002-09-26 14:51 Exhaustive simulator testing Zack Weinberg
@ 2002-09-27  3:11 ` Richard Earnshaw
  2002-09-27 10:16   ` Tom Tromey
  2002-10-02  7:29 ` Jeff Law
  2002-10-18  6:53 ` Ben Elliston
  2 siblings, 1 reply; 9+ messages in thread
From: Richard Earnshaw @ 2002-09-27  3:11 UTC (permalink / raw)
  To: Zack Weinberg; +Cc: gcc, Richard.Earnshaw

> Mostly to see what would happen, I wrote a script that built and
> tested the combined tree for every last target in the matrix I posted
> yesterday as part of the simtest-howto rewrite.

> arm-elf                  pass  fail  xpass xfail  unres unsup untest
>         binutils           31     1
>         gas                63
>         ld                 29                  3
>         newlib              5     1
>         gdb              6832   291           51     30    11      9
>         gcc             20211    26      1    63     42   150

He He: here's a more complete list from my own runs, including some 
multi-lib varaints...

All tests run from a compiler checked out at: Thu Sep 26 08:44:01 UTC 2002

configuration: arm-elf 

arm-sim
			pass  fail  xpass xfail  unres  unsup untest
	binutils	  31     1
	gas		  64
	ld		  29                  3
	newlib[1]	   5     1
	gdb[2]		6447   264           64    493      7
	gcc	       20662    26      1    63     42    151
	g++		7463    15           93     21     11    29
	g77		1564    43                  31      9     8
	objc            1153
	libjava[3]	2034    18           14                 104
	libstdc++	tests not run -- ?? couldn't locate runtest

arm-sim/-mhard-float
			pass  fail  xpass xfail  unres  unsup untest
	binutils	  31     1
	gas		  64
	ld		  29     3
	newlib[1]	   5     1
	gdb[2]		6238   276           64    596     7
	gcc	       20534   154           64     42   151
	g++		7463    15           93     21    11     29
	g77		1559    47                  21     9      8
	objc            1153
	libjava[3]	2034    18           14                 104
	libstdc++	tests not run -- ?? couldn't locate runtest

arm-sim/-mthumb
			pass  fail  xpass xfail  unres  unsup untest
	binutils	  31     1
	gas		  64
	ld		  29     3
	newlib[1]	   5     1
	gdb[2]		6280   390           64    466     7
	gcc	       20649    36      2    62     44   151
	g++		7491    58           93     21    11     29
	g77		1560    46                  21     9      8
	objc            1153
	libjava[3]	2035    18           14                 103
	libstdc++	tests not run -- ?? couldn't locate runtest


Notes:
[1]  Newlib tests are run in every multi-lib variant on every pass; 
typically all tests will fail if the multi-lib does not match the test 
config ;-(
[2]  My gdb sources contain major changes from the mainline, so are not 
really representative.
[3]  Libjava requires some minor changes to enable the package for arm-elf.

R.

PS. Does your script also produce the above summary tables?  Something to 
do that automatically would be very cool.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Exhaustive simulator testing
  2002-09-27  3:11 ` Richard Earnshaw
@ 2002-09-27 10:16   ` Tom Tromey
  2002-09-28  7:16     ` Richard Earnshaw
  0 siblings, 1 reply; 9+ messages in thread
From: Tom Tromey @ 2002-09-27 10:16 UTC (permalink / raw)
  To: Richard.Earnshaw; +Cc: gcc

>>>>> "Richard" == Richard Earnshaw <rearnsha@arm.com> writes:

Richard> [3] Libjava requires some minor changes to enable the package
Richard> for arm-elf.

Are these changes suitable for checkin?

Tom

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Exhaustive simulator testing
  2002-09-27 10:16   ` Tom Tromey
@ 2002-09-28  7:16     ` Richard Earnshaw
  0 siblings, 0 replies; 9+ messages in thread
From: Richard Earnshaw @ 2002-09-28  7:16 UTC (permalink / raw)
  To: tromey; +Cc: Richard.Earnshaw, gcc

> >>>>> "Richard" == Richard Earnshaw <rearnsha@arm.com> writes:
> 
> Richard> [3] Libjava requires some minor changes to enable the package
> Richard> for arm-elf.
> 
> Are these changes suitable for checkin?
> 
> Tom

Yep, indeed I'd been planning to check them in today before I read your 
mail.

R.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Exhaustive simulator testing
  2002-09-26 14:51 Exhaustive simulator testing Zack Weinberg
  2002-09-27  3:11 ` Richard Earnshaw
@ 2002-10-02  7:29 ` Jeff Law
  2002-10-02 14:00   ` Alexandre Oliva
  2002-10-18  6:53 ` Ben Elliston
  2 siblings, 1 reply; 9+ messages in thread
From: Jeff Law @ 2002-10-02  7:29 UTC (permalink / raw)
  To: Zack Weinberg; +Cc: gcc


In message <20020926214630.GG12223@codesourcery.com>, Zack Weinberg writes:
 >Mostly to see what would happen, I wrote a script that built and
 >tested the combined tree for every last target in the matrix I posted
 >yesterday as part of the simtest-howto rewrite.
 >
 >Just over half of them fail to build for various reasons:
 >
 >d10v-elf        - not supported by GCC
 >mn10200-elf     - not supported by GCC (obsoleted target)
Note that the mn102 may need to be resurrected.  I'm hearing some rumblings
that it is being used inside Matsushita.  Luckily it shouldn't be in
terrible shape.  I built it a couple months ago and fixed a handful of
failures.

 >mn10300-elf     - GAS barfs during build
 >
 >_muldi3.s: Assembler messages:
 >_muldi3.s:829: Error: can't resolve `.Letext0' {.text section} 
 >    - `.Ltext0' {.text section}
Alex -- can you look at this?

Jeff


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Exhaustive simulator testing
  2002-10-02  7:29 ` Jeff Law
@ 2002-10-02 14:00   ` Alexandre Oliva
  0 siblings, 0 replies; 9+ messages in thread
From: Alexandre Oliva @ 2002-10-02 14:00 UTC (permalink / raw)
  To: law; +Cc: Zack Weinberg, gcc

On Oct  2, 2002, Jeff Law <law@porcupine.cygnus.com> wrote:

>> _muldi3.s: Assembler messages:
>> _muldi3.s:829: Error: can't resolve `.Letext0' {.text section} 
>> - `.Ltext0' {.text section}
> Alex -- can you look at this?

Yeah, it's been in my to-do list for a while already.  I suspect an
assembler problem, since the assembly output looks right.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Exhaustive simulator testing
  2002-09-26 14:51 Exhaustive simulator testing Zack Weinberg
  2002-09-27  3:11 ` Richard Earnshaw
  2002-10-02  7:29 ` Jeff Law
@ 2002-10-18  6:53 ` Ben Elliston
  2002-10-30 14:21   ` Zack Weinberg
  2 siblings, 1 reply; 9+ messages in thread
From: Ben Elliston @ 2002-10-18  6:53 UTC (permalink / raw)
  To: gcc

>>>>> "Zack" == Zack Weinberg <zack@codesourcery.com> writes:

  Zack> It Would Be Nice if it were possible to build the simulator
  Zack> without also building GDB.  It Would Be Really Nice if you
  Zack> didn't have to have GDB's sources in the tree at all.

Are you sure?  Most simulators can be built without having to first
build GDB -- you just configure src/sim (or src/sid, if you're lucky
enough) and it will produce a standalone <target>-run executable.

Ben


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Exhaustive simulator testing
  2002-10-18  6:53 ` Ben Elliston
@ 2002-10-30 14:21   ` Zack Weinberg
  2002-10-31  8:54     ` Phil Edwards
  0 siblings, 1 reply; 9+ messages in thread
From: Zack Weinberg @ 2002-10-30 14:21 UTC (permalink / raw)
  To: Ben Elliston; +Cc: gcc

On Fri, Oct 18, 2002 at 09:52:44PM +1000, Ben Elliston wrote:
> >>>>> "Zack" == Zack Weinberg <zack@codesourcery.com> writes:
> 
>   Zack> It Would Be Nice if it were possible to build the simulator
>   Zack> without also building GDB.  It Would Be Really Nice if you
>   Zack> didn't have to have GDB's sources in the tree at all.
> 
> Are you sure?  Most simulators can be built without having to first
> build GDB -- you just configure src/sim (or src/sid, if you're lucky
> enough) and it will produce a standalone <target>-run executable.

Many of the src/sim simulators make direct reference to GDB routines.
For instance, sim/ppc/main.c and sim/ppc/sim_calls.c both include
gdb/callback.h and gdb/remote-sim.h.  If the GDB sources are not in
the tree these files will obviously not compile.  My experience is
that if GDB is in the tree but hasn't been configured, they still
won't compile (bombs out looking for gdb/config.h or similar).

I haven't looked at sid.

zw

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Exhaustive simulator testing
  2002-10-30 14:21   ` Zack Weinberg
@ 2002-10-31  8:54     ` Phil Edwards
  0 siblings, 0 replies; 9+ messages in thread
From: Phil Edwards @ 2002-10-31  8:54 UTC (permalink / raw)
  To: Zack Weinberg; +Cc: Ben Elliston, gcc

On Wed, Oct 30, 2002 at 11:32:50AM -0800, Zack Weinberg wrote:
> 
> Many of the src/sim simulators make direct reference to GDB routines.
> For instance, sim/ppc/main.c and sim/ppc/sim_calls.c both include
> gdb/callback.h and gdb/remote-sim.h.  If the GDB sources are not in
> the tree these files will obviously not compile.  My experience is
> that if GDB is in the tree but hasn't been configured, they still
> won't compile (bombs out looking for gdb/config.h or similar).

Yes.  When building a combined tree for cross-targets, I have to configure
all of it, then delete gdb/Makefile -- and nothing else -- to avoid building
a debugger.


Phil

-- 
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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2002-10-31  0:07 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-09-26 14:51 Exhaustive simulator testing Zack Weinberg
2002-09-27  3:11 ` Richard Earnshaw
2002-09-27 10:16   ` Tom Tromey
2002-09-28  7:16     ` Richard Earnshaw
2002-10-02  7:29 ` Jeff Law
2002-10-02 14:00   ` Alexandre Oliva
2002-10-18  6:53 ` Ben Elliston
2002-10-30 14:21   ` Zack Weinberg
2002-10-31  8:54     ` Phil Edwards

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).