[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20091105173842.c94ba501.sfr@canb.auug.org.au>
Date: Thu, 5 Nov 2009 17:38:42 +1100
From: Stephen Rothwell <sfr@...b.auug.org.au>
To: Rusty Russell <rusty@...tcorp.com.au>
Cc: Hollis Blanchard <hollisb@...ibm.com>,
Jan Beulich <JBeulich@...ell.com>, akpm@...ux-foundation.org,
linuxppc-dev@...ts.ozlabs.org, kvm-ppc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-next@...r.kernel.org
Subject: Re: [PATCH] BUILD_BUG_ON: make it handle more cases
Hi Rusty,
On Thu, 5 Nov 2009 16:58:36 +1030 Rusty Russell <rusty@...tcorp.com.au> wrote:
>
> Huh? virtio_has_feature does:
>
> if (__builtin_constant_p(fbit))
> BUILD_BUG_ON(fbit >= 32);
> else
> BUG_ON(fbit >= 32);
In Linus' tree (and linux-next) it looks like this:
static inline bool virtio_has_feature(const struct virtio_device *vdev,
unsigned int fbit)
{
/* Did you forget to fix assumptions on max features? */
MAYBE_BUILD_BUG_ON(fbit >= 32);
if (fbit < VIRTIO_TRANSPORT_F_START)
virtio_check_driver_offered_feature(vdev, fbit);
return test_bit(fbit, vdev->features);
}
> So, if it's not a constant, gcc should throw away that first branch. If it
> is, it should optimize it away (and no, these are not real bugs AFAICT).
Your version above may well fix the problem. Alternatively marking it
__always_inline way work as well.
> I did a 4.3.3 allmodconfig with this patch on 64-bit a few days back and all
> was fine. Will try 4.4.0 now.
4.4 is more problematic.
--
Cheers,
Stephen Rothwell sfr@...b.auug.org.au
http://www.canb.auug.org.au/~sfr/
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists