All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>
Cc: "bugme-daemon@kernel-bugs.osdl.org" 
	<bugme-daemon@bugzilla.kernel.org>,
	linux-kernel@vger.kernel.org, malitzke@metronets.com,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [Bug 8501] udivdi3  absence with gcc-4.3.0 on kernels 2.6.20.11 & 2.6.22.-rc1
Date: Fri, 18 May 2007 15:29:35 -0700	[thread overview]
Message-ID: <20070518152935.b5a4b3bf.akpm@linux-foundation.org> (raw)
In-Reply-To: <200705181941.l4IJfOtf018049@fire-2.osdl.org>

On Fri, 18 May 2007 12:41:24 -0700
bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=8501

Problem.

gcc-4.3 appears to have cunningly converted this:

static inline void timespec_add_ns(struct timespec *a, u64 ns)
{
	ns += a->tv_nsec;
	while(unlikely(ns >= NSEC_PER_SEC)) {
		ns -= NSEC_PER_SEC;
		a->tv_sec++;
	}
	a->tv_nsec = ns;
}

into a divide-by-1000000000 operation, so it emits a call to udivdi3 and we
don't link.

I expect that this optimisation will remain in gcc-4.3 and we'll end up
having major kernel releases which don't build on i386 with major gcc
releases, which isn't altogether desirable.  I suspect we'll need to fix this
fairly urgently, and to backport the fix into a number of kernel releases.

We use the above idiom in several places.  A suitable fix might be to hunt
down those various sites and then make them call a helper function which
does

	if (unlikely(ns >= NSEC_PER_SEC)) {
		do_div(...)
	}

(Better would be to inline the comparison and to uninline the do_div(),
if it's a 32-bit arch.  Doing all this in a backportable fashion may
prove tricky)

       reply	other threads:[~2007-05-18 22:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200705181941.l4IJfOtf018049@fire-2.osdl.org>
2007-05-18 22:29 ` Andrew Morton [this message]
2007-05-18 23:05   ` [Bug 8501] udivdi3 absence with gcc-4.3.0 on kernels 2.6.20.11 & 2.6.22.-rc1 Adrian Bunk
2007-05-18 23:12   ` Thomas Gleixner
2007-05-18 23:15   ` Linus Torvalds
2007-05-18 23:39   ` Segher Boessenkool

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=20070518152935.b5a4b3bf.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=bugme-daemon@bugzilla.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=malitzke@metronets.com \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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 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.