mrg@eterna.com.au wrote:

>    >> #define bus_space_barrier(t, h, o, l, f)	\
>    >> 	((void)((void)(t), (void)(h), (void)(o), (void)(l), (void)(f)),	\
>    >> 	 wbflush())

>    What is a good way to appease gcc4 for this?
>    Just putting wbflush() at left-hand?

> hmm, shouldn't this really just be defined as wbflush() and avoid
> all those (void) casts? or are those there to avoid unused argument
> warnings?

Maybe. Even i386 and other ports which don't require any barrier ops
have the similar void casts.

>    > xfree/xc/programs/Xserver/mfb/mfbfillsp.c:813: \
>    > warning: matching constraint does not allow a register

>    FASTGETBITS() in xfree/xc/programs/Xserver/mfb/maskbit.h?
>    I also see the same warnings around __cpu_simple_lock() and
>    __cpu_simple_lock_try() in sys/arch/mips/include/lock.h.
>    
>    It seems gcc4 rejects registers for memory operand constrains
>    ("m" or "o"). Is it okay to use constraints "p" instead?

> hmmm.  it's been too long for m68k and me, if it works it
> probably is OK :-)

gcc4 doesn't complain with "p" at least mips/include/lock.h,
but I can't confirm whether proper code is generated in that case.
Maybe we should ask gcc guru about usage of these constraints...
---
Izumi Tsutsui