Ian Dall wrote:

> [ toolchain work ]

This is great Ian!

> o  ELF is still not available for this port. Can we not assume ELF for a bit
>    longer, even in the case of USE_NEW_TOOLCHAIN/ I think we should go to
>    ELF for this port, but in the interim, it would be helpful.

The plan is to work off the Vax ELF changes for ns32k.  Not having ELF
in the short term will be ok until Nathan Williams Scheduler Activations
branch gets merged to the trunk.  This isn't too far off I believe, but
I'm sure we can make the pc532 port limp along until ELF arrives.

> o  I certainly intend to submit patches to the gcc people and the binutils
>    people. Is that sufficient or should they go in parallel somewhere to
>    make sure they get in the netbsd tree? Bear in mind that they have not
>    been made against, or tested with, the versions in the netbsd tree.

We haven't decided on a future target for gcc yet.  I'm sure Jason could
explain more fully.  There was some talk on the future toolchain on
tech-toolchain a month or so ago.


Related to this, I've been playing around with gcc-current and
have two test cases failing that are worrying.  Also, using
"-fomit-frame-pointer" causes lots of execution failures (but not
every time).  The two failures are:

 1) An "unrecognizable insn" error for
    testsuite/gcc.c-torture/compile/900313-1.c

 2) An execution failure for gcc.c-torture/execute/20020201-1.c -O0
    Basically:

	unsigned char cx = 7;
	unsigned char cy;

	cy = cx / 6;

    and cy = 0, instead of 1.  It appears to put a 0 in the current
    stack frame, go to all the trouble of doing the calculation, then
    reads the 0 from the frame over the result.  After talking to Jason,
    it appears that this might be some sort of sign extension problem.
    Using any sort of optimising on this test case doesn't have the
    problem.

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/