Attached a diff against the last fully working CVS Snapshot I had.  
(ie, before mp was commited)

On 11.12.2005, at 21:47, Joachim Henke wrote:

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

I'm now scanning thru the changes in exec.c...

>> I hope Fabrice stumbles upon this.
>>
>> Maybe we should make the Patch a little more selective with "ifeq  
>> ($(CONFIG_DARWIN),yes)" and post it.
>> Don't know whether this affects other Platforms, too...
>
> Yes, my patch was just a simple one for experimental purposes. It  
> must not go into CVS since it breaks compilation with GCC3 or  
> earlier. Despite the fact that GCC4 is required only for cpu- 
> exec.c, I also think that building with GCC4 should be generally  
> provided, since all emulated architectures compile cleanly with it  
> (at least on Mac OS X).
>
> Instead of requiring --disable-gcc-check, the configure script  
> could write the option HAVE_GCC4=yes to config-host.mak, if it  
> detects GCC4. The warning message could be kept. Makefile.target  
> can then decide which CFLAGS should be used.
>
> I could create such a patch if people agree.

my guess is, that things stay as they are, since gcc4 is not a target  
in the near future as stated many times. The GCC4 warnings was only  
added, because there where a lot of annoying posts on the list about  
"can't compile on GCC4". So GCC4 is only a workaround :) for now.  
Thing is, that only qemu-system is working when compiled by gcc4,  
qemu-user not.

Mike