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.
Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
