Re: [2.6.37-rc1] Build failure: __divdi3

[Andrew Morton <akpm@linux-foundation.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?