From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [2.6.37-rc1] Build failure: __divdi3
Date: Fri, 5 Nov 2010 10:53:45 -0700
Message-ID: <20101105105345.60d7ad6b.akpm@linux-foundation.org>
References: <201011050859.oA58xgCS071292@www262.sakura.ne.jp>
	<20101105090925.1f6e4b00.rdunlap@xenotime.net>
	<201011060148.AHA93123.FHOOMJSLtFFVOQ@I-love.SAKURA.ne.jp>
	<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>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	rdunlap@xenotime.net, jmorris@namei.org,
	linux-fsdevel@vger.kernel.org
To: Eric Paris <eparis@redhat.com>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from smtp1.linux-foundation.org ([140.211.169.13]:39602 "EHLO
	smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1752573Ab0KERyF (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Fri, 5 Nov 2010 13:54:05 -0400
In-Reply-To: <1288978905.20262.62.camel@localhost.localdomain>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Fri, 05 Nov 2010 13:41:45 -0400
Eric Paris <eparis@redhat.com> wrote:

> On Sat, 2010-11-06 at 02:16 +0900, Tetsuo Handa wrote:
> > Tetsuo Handa wrote:
> > > Eric Paris wrote:
> > > > Interesting, is this a result of the compiler previously being able to
> > > > optimize the division since it could tell it was a power of 2 and now
> > > > that we have a private variable it can't?  The patch can easily be
> > > > reverted without breaking anyone else....
> > > 
> > I meant to say that it seems that GCC 3.x can optimize
> > 
> >   #define roundup(x, y) ((((x) + ((y) - 1)) / (y)) * (y))
> > 
> > for roundup((long long), (const)) case but cannot optimize
> > 
> >   #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?