Subject: Re: gcc4 status
To: None <email@example.com>
From: Izumi Tsutsui <firstname.lastname@example.org>
Date: 05/23/2006 20:05:49
> >> #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
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...