I tried building a -current mac68k kernel with the newly-imported gcc
4, and ran into a few errors, most of which I'm not too sure about
how to solve.

First is:
/usr/src.local/sys/arch/mac68k/mac68k/macrom.c: In function 'mrg_DTInstall':
/usr/src.local/sys/arch/mac68k/mac68k/macrom.c:180: error: invalid lvalue in assignment

        caddr_t ptr, prev;

        __asm volatile ("movl %%a0,%0" : "=g" (ptr));

        (caddr_t *)prev = &mrg_DTList;
 
I think changing the last line to:
	prev = (caddr_t)&mrg_DTList;
will do the same thing.

After changing that, I run into another problem in macrom.c:
/usr/src.local/sys/arch/mac68k/mac68k/macrom.c: In function 'mrg_aline_super':
/usr/src.local/sys/arch/mac68k/mac68k/macrom.c:728: error: unknown register name 'fp' in 'asm'

/* 	put a0 in a0 */
/* 	put a1 in a1 */
/* 	put d0 in d0 */
/* 	put d1 in d1 */
/*	put trapaddr in a2 */
/* save a6 */
/* 	call the damn routine */
/* restore a6 */
/* 	store d0 in d0bucket */
/* 	store a0 in d0bucket */
/* This will change a2,a1,d1,d0,a0 and possibly a6 */

	__asm volatile (
	"	movl	%2@,%%d0	\n"
	"	movl	%2@(4),%%d1	\n"
	"	movl	%2@(32),%%a0	\n"
	"	movl	%2@(36),%%a1	\n"
	"	movl	%3,%%a2		\n"
	"	jbsr	%%a2@		\n"
	"	movl	%%a0,%0		\n"
	"	movl	%%d0,%1"

		: "=g" (a0bucket), "=g" (d0bucket)

		: "a" (&frame->f_regs), "g" (trapaddr)

		: "d0","d1","a0","a1","a2",
#ifdef __ELF__
			  "fp"
#else
			  "a6"
#endif

I don't know why the clobber register spec is "fp" for ELF and "a6"
otherwise... isn't "fp" just an alias for "a6"? I tried changing it to
use "a6" unconditionally, but that doesn't work either:

/usr/src.local/sys/arch/mac68k/mac68k/macrom.c: In function 'mrg_aline_super':
/usr/src.local/sys/arch/mac68k/mac68k/macrom.c:763: error: %a6 cannot be used in asm here

The comments say "save a6" and "restore a6", but I don't see where
that happens. They also say that it'll possibly change A6, but I don't
see when that would happen either. Are there some ROM toolbox calls
that will modify A6? That seems like it'd be a bad thing for a
subroutine to not restore the frame pointer...

Anyways, I don't know if it's the right thing to do, but I just
removed fp/a6 from the list of clobbered registers.

That gets us past macrom.c and on to this:
cc1: warnings being treated as errors
/usr/src.local/sys/arch/m68k/m68k/pmap_motorola.c: In function 'pmap_changebit':
/usr/src.local/sys/arch/m68k/m68k/pmap_motorola.c:2518: warning: 'pg_' may be used uninitialized in this function
/usr/src.local/sys/arch/m68k/m68k/pmap_motorola.c:2525: warning: 'pg_' may be used uninitialized in this function

It's complaining about these two macros:

#define	pa_to_pvh(pa)							\
({									\
	int bank_, pg_;							\
									\
	bank_ = vm_physseg_find(atop((pa)), &pg_);			\
	&vm_physmem[bank_].pmseg.pvent[pg_];				\
})

#define	pa_to_attribute(pa)						\
({									\
	int bank_, pg_;							\
									\
	bank_ = vm_physseg_find(atop((pa)), &pg_);			\
	&vm_physmem[bank_].pmseg.attrs[pg_];				\
})

And I suppose that gcc is right that vm_physseg_find may not set
pg_... it looks like vm_physseg_find returns -1 if it didn't find what
it was looking for, but I don't know how to check for that due to the
way those macros are written. Initializing pg_=0 gets rid of the
warning, but it seems like that's just sweeping the problem under the
rug :)
-- 
Name: Dave Huang         |  Mammal, mammal / their names are called /
INet: khym@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan         |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 30 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++