Martin Husemann said:
>> So sh is broken on NetBSD-current and NetBSD 2.0.x when compiled natively.
>> This seems like more subtle problems with GCC 3.3.3.
>
>Both of this "conclusions" have not been proven yet.
>
>Since you can easily reproduce the failure, how about a sh build with DBG=-g
>and using gdb to see why it cores? And file a PR with the results.

So far, an sh build with DBG=-g doesn't coredump at all. I built sh from
tools that were built using ksh as "sh". The full build did fail due to
some changes in man pages. I updated from anoncvs and I'm doing another
build. (sh ./build.sh -O /usr/obj build)

GCC 3.3.3 does have some problems.

emacs 21.3

Builds on NetBSD 1.5.4 gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
          NetBSD gcc version 2.95.3 20010315 (release) (NetBSD nb3)
	  Solaris 8 gcc version 2.95.3 20010315 (release)
          Solaris 8 gcc version 3.4.2
          Slackware 10 gcc version 3.3.4
          FreeBSD 5.3-RELEASE gcc version 3.4.2 [FreeBSD] 20040728

Does not build on
          NetBSD 2.x.x	gcc version 3.3.3 (NetBSD nb3 20040520)
	  NetBSD-current 3.99.3 gcc version 3.3.3 (NetBSD nb3 20040520)

The two failing cases are bad code produced by GCC. The only reaction that
I have seen is that emacs was hacked to work in pkgsrc. Previously, I have
never had any problems building emacs anywhere. There are other examples of
common (old even) sources that don't compile cleanly under GCC 3.3.3, but
are hacked to work in pkgsrc.
-- 
Rick Kelly	rmk@rmkhome.com
		<http://www.rmkhome.com/>
		<http://rkba.rmkhome.com/> - the right to keep and bear arms
		<http://wolf.rmkhome.com/> - firearm forums