linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Chris Mason <chris.mason@oracle.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] btrfs: fix __ucmpdi2 compile bug on 32 bit builds
Date: Sat, 28 Mar 2009 10:38:50 +0100	[thread overview]
Message-ID: <87prg26l79.fsf@basil.nowhere.org> (raw)
In-Reply-To: <20090327134252.0f24773b@osiris.boeblingen.de.ibm.com> (Heiko Carstens's message of "Fri, 27 Mar 2009 13:42:52 +0100")

Heiko Carstens <heiko.carstens@de.ibm.com> writes:

> From: Heiko Carstens <heiko.carstens@de.ibm.com>
>
> We get this on 32 builds:
>
> fs/built-in.o: In function `extent_fiemap':
> (.text+0x1019f2): undefined reference to `__ucmpdi2'

>
> Happens because of a switch statement with a 64 bit argument.
> Convert this to an if statement to fix this.


To be honest that sounds more like a bug in your architecture.

I don't think it's the right solution to make a new rule
"you shall not do 64bit switch()", because that's a reasonable
thing to do and will be hard to enforce over millions of lines
of random Linux code.

There was a explicit decision to not support implicit 64bit 
divides on 32bit because they're very costly, but that doesn't
really apply to 64bit switch(). At least they shouldn't be very costly
in theory. It seems indeed weird to call a function to compare
a 64bit value. I bet the call sequence is larger than just 
doing two cmps. Perhaps your gcc should be fixed? Or alternatively
at least that function be added to the kernel runtime library.

-Andi


ak@linux.intel.com -- Speaking for myself only.

  parent reply	other threads:[~2009-03-28  9:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-27 12:42 [PATCH] btrfs: fix __ucmpdi2 compile bug on 32 bit builds Heiko Carstens
2009-03-27 14:16 ` Stephen Rothwell
2009-03-27 14:24   ` Kyle McMartin
2009-03-27 14:37     ` Chris Mason
2009-03-28  9:38 ` Andi Kleen [this message]
2009-03-29 19:22   ` Kyle McMartin

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=87prg26l79.fsf@basil.nowhere.org \
    --to=andi@firstfloor.org \
    --cc=chris.mason@oracle.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).