[lkml]   [2007]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Bug 8501] udivdi3 absence with gcc-4.3.0 on kernels & 2.6.22.-rc1
    > 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.

    Exactly. It obviously is a bug in the kernel that it depends
    on certain compiler optimisations that it doesn't have direct
    control over to happen or not. OTOH, GCC's behaviour here is
    probably a non-optimal code issue; it doesn't seem to take the
    unlikely() into account when doing the loop transform.

    > I expect that this optimisation will remain in gcc-4.3

    If someone files a *useable* problem report it most likely
    will be taken care of, actually.

    > and we'll end up
    > having major kernel releases which don't build on i386 with major gcc
    > releases, which isn't altogether desirable.

    Yeah, like 4.2.0 with powerpc. Seems like no one tested it :-(

    > I suspect we'll need to fix this
    > fairly urgently, and to backport the fix into a number of kernel
    > releases.

    If it is 4.3 only, you could instead try to work *with* the GCC
    people. It _is_ very fragile code of course, it wouldn't hurt
    to replace it with something better.

    > 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)

    Perhaps putting a compiler barrier in there would be enough -- like
    an empty asm() that takes the loop variable as input.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-05-19 01:43    [W:0.022 / U:72.928 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site