From: Eric Paris <eparis@redhat.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: rdunlap@xenotime.net, akpm@linux-foundation.org,
jmorris@namei.org, linux-fsdevel@vger.kernel.org
Subject: Re: [2.6.37-rc1] Build failure: __divdi3
Date: Fri, 05 Nov 2010 13:41:45 -0400 [thread overview]
Message-ID: <1288978905.20262.62.camel@localhost.localdomain> (raw)
In-Reply-To: <201011060216.GCF30239.OOLMVQSHtFFOFJ@I-love.SAKURA.ne.jp>
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?
-Eric
next prev parent reply other threads:[~2010-11-05 17:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-05 8:59 [2.6.37-rc1] Build failure: __divdi3 Tetsuo Handa
2010-11-05 16:09 ` Randy Dunlap
2010-11-05 16:48 ` Tetsuo Handa
2010-11-05 16:55 ` Eric Paris
2010-11-05 17:08 ` Tetsuo Handa
2010-11-05 17:16 ` Tetsuo Handa
2010-11-05 17:41 ` Eric Paris [this message]
2010-11-05 17:53 ` Andrew Morton
2010-11-05 18:36 ` Tetsuo Handa
2010-11-09 0:13 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1288978905.20262.62.camel@localhost.localdomain \
--to=eparis@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=jmorris@namei.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=rdunlap@xenotime.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.