gcc4 and -fno-tree-ch did the trick for me, too.
-fno-tree-ch was mentioned earlyer on this list, to compile with
gcc4 on OS X. But since gcc4 is still not in the default
toolchain, I did not even try :(.
Seams that we have a problem with gcc3.3 and not gcc4 for once :)
The error behavement is similar on your machine. I also got bus
error (Sometimes it did not reach the menu, too. I started to hit
the 3 very early, so I could go right thru it... Early crashes
always happened for me on MS-DOS 6.22 and DOS 7.
Tested it with DOS 6.22 and DOS 7 (win95). No Problems so far.
In the meanwhile I tracked down the whole thing a little bit.
Debugging with GDB returns these messages when qemu (pure GCC3
build) crashes:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000034
0x000621e0 in tb_invalidate_phys_page_range (start=630485,
end=630486, is_cpu_write_access=1) at /Volumes/Data/build/qemu/
exec.c:491
491 tb2 = tb1->jmp_next[n1];
So one could assume that the problem is in exec.c - but some more
compiling tests have shown, that GCC4 is required _only_ for cpu-
exec.c. All other source files can be build with GCC3 and qemu will
still run stable on Mac OS X (such a mixed build is probably faster
than a pure GCC4 build). I feel indeed that the problem is
somewhere in cpu-exec.c or one of its includes - maybe they init
the data that exec.c crashes on. Hopefully I'm a bit luckier to
find it tomorrow.