Messages in this thread | | | From | Segher Boessenkool <> | Subject | Re: [Bug 8501] udivdi3 absence with gcc-4.3.0 on kernels 2.6.20.11 & 2.6.22.-rc1 | Date | Sat, 19 May 2007 01:39:43 +0200 |
| |
> 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.
Segher
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |