From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [2.6.37-rc1] Build failure: __divdi3 Date: Mon, 8 Nov 2010 16:13:44 -0800 Message-ID: <20101108161344.1d508a72.akpm@linux-foundation.org> References: <1288976127.20262.58.camel@localhost.localdomain> <201011060208.JFJ39521.HFQLOVtFOSJOMF@I-love.SAKURA.ne.jp> <201011060216.GCF30239.OOLMVQSHtFFOFJ@I-love.SAKURA.ne.jp> <1288978905.20262.62.camel@localhost.localdomain> <20101105105345.60d7ad6b.akpm@linux-foundation.org> <201011060336.GHC90161.OMVOtHSFFJOQFL@I-love.SAKURA.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: eparis@redhat.com, rdunlap@xenotime.net, jmorris@namei.org, linux-fsdevel@vger.kernel.org To: Tetsuo Handa Return-path: Received: from smtp1.linux-foundation.org ([140.211.169.13]:45792 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753014Ab0KIAO3 (ORCPT ); Mon, 8 Nov 2010 19:14:29 -0500 In-Reply-To: <201011060336.GHC90161.OMVOtHSFFJOQFL@I-love.SAKURA.ne.jp> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sat, 6 Nov 2010 03:36:27 +0900 Tetsuo Handa wrote: > Andrew Morton wrote: > > > > #define roundup(x, y) ( \ > > > > { \ > > > > typeof(y) __y = y; \ > > > > (((x) + (__y - 1)) / __y) * __y; \ > > > > } \ > > > > ) > > > > > > > > for roundup((long long), (const)) case. > > > > > > I guess this is my fault (I'm not completely convinced) since my testing > > > was done with gcc 4. I just retested to make sure that > > > gcc-4.5.1-4.fc14.x86_64 is able to optimize both (and it does). Is the > > > fact that it requires compiler optimizations for the code to build a > > > good thing? > > > > It does make us pretty fragile against future compiler versions, but we > > do rely quite a lot on such compiler things. And things do break, such > > as the several-month outbreak of calls to > > you_cannot_kmalloc_that_much() a while back. > > > > I wonder if there's some way of tricking gcc back into doing the right > > thing here. Make __y const or something? > > Nice suggestion. > > -typeof(y) __y = y; > +const typeof(y) __y = y; > > solved __divdi3 problem with GCC 3.3.5. > OK, thanks. Pending any better ideas, I typed this in: From: Andrew Morton gcc-3.3.5 (at least) is failing to optimise away the divide when `y' is a constant 64-bit power-of-two value - it emits a call to __divdi3(). It turns out that defining `y' as const prevents this. Reported-by: Tetsuo Handa Tested-by: Tetsuo Handa Cc: Randy Dunlap Cc: Eric Paris Cc: James Morris Signed-off-by: Andrew Morton --- include/linux/kernel.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff -puN include/linux/kernel.h~include-linux-kernelh-roundup-work-around-a-gcc-33-miscompile include/linux/kernel.h --- a/include/linux/kernel.h~include-linux-kernelh-roundup-work-around-a-gcc-33-miscompile +++ a/include/linux/kernel.h @@ -58,9 +58,11 @@ extern const char linux_proc_banner[]; #define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f)) #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d)) + +/* The `const' in roundup() prevents gcc-3.3 from calling __divdi3 */ #define roundup(x, y) ( \ { \ - typeof(y) __y = y; \ + const typeof(y) __y = y; \ (((x) + (__y - 1)) / __y) * __y; \ } \ ) _