Why are we building kernels with this broken compiler?
http://bugzilla.kernel.org/show_bug.cgi?id=8501
http://koji.fedoraproject.org/koji/getfile?taskID=388196&name=build.log
Why are we building kernels with this broken compiler?
http://bugzilla.kernel.org/show_bug.cgi?id=8501
http://koji.fedoraproject.org/koji/getfile?taskID=388196&name=build.log
Why are we building these broken kernels with our shiny new compiler?
On Thu, Jan 31, 2008 at 04:47:55PM -0800, Roland McGrath wrote:
Why are we building kernels with this broken compiler?
http://bugzilla.kernel.org/show_bug.cgi?id=8501
http://koji.fedoraproject.org/koji/getfile?taskID=388196&name=build.log
Why are we building these broken kernels with our shiny new compiler?
Does using -ffreestanding fix these references to libgcc? I notice we're not using it when we build x86 or powerpc kernels, where we see this...
cheers, Kyle
On Thu, Jan 31, 2008 at 07:50:42PM -0500, Kyle McMartin wrote:
On Thu, Jan 31, 2008 at 04:47:55PM -0800, Roland McGrath wrote:
Why are we building kernels with this broken compiler?
http://bugzilla.kernel.org/show_bug.cgi?id=8501
http://koji.fedoraproject.org/koji/getfile?taskID=388196&name=build.log
Why are we building these broken kernels with our shiny new compiler?
Does using -ffreestanding fix these references to libgcc? I notice we're not using it when we build x86 or powerpc kernels, where we see this...
No, even -ffreestanding assumes libgcc is used. libgcc.a is mostly[1] self-contained and assumed to be present in both -fhosted and -ffreestanding linking. This is nothing new, has been like that for many years. AFAIK kernel on several architectures uses libgcc.a, on those where it intentionally decides not to do that, it either needs to supply its own implementation of the needed entrypoints, or make sure they are not needed. In this case you should put in an asm optimization barrier into the loop to avoid optimizing the loop into modulo. See the gcc PR opened for it.
[1] exceptions are that __eprintf assumes stdio, -ftrapv helpers assume abort, the rest is really self-contained, and kernel really has no reason to use either __eprintf, nor is compiled with -ftrapv
Jakub
On 02/01/2008 03:46 AM, Jakub Jelinek wrote:
On Thu, Jan 31, 2008 at 07:50:42PM -0500, Kyle McMartin wrote:
On Thu, Jan 31, 2008 at 04:47:55PM -0800, Roland McGrath wrote:
Why are we building kernels with this broken compiler?
http://bugzilla.kernel.org/show_bug.cgi?id=8501
http://koji.fedoraproject.org/koji/getfile?taskID=388196&name=build.log
Why are we building these broken kernels with our shiny new compiler?
Does using -ffreestanding fix these references to libgcc? I notice we're not using it when we build x86 or powerpc kernels, where we see this...
No, even -ffreestanding assumes libgcc is used. libgcc.a is mostly[1] self-contained and assumed to be present in both -fhosted and -ffreestanding linking. This is nothing new, has been like that for many years. AFAIK kernel on several architectures uses libgcc.a, on those where it intentionally decides not to do that, it either needs to supply its own implementation of the needed entrypoints, or make sure they are not needed. In this case you should put in an asm optimization barrier into the loop to avoid optimizing the loop into modulo. See the gcc PR opened for it.
The below patch fixes it too, but that just leads to the next error (on ppc64):
drivers/input/mouse/psmouse-base.c:45: error: __param_proto causes a section type conflict
Was someone supposed to test building the kernel package with the new compiler before making it the default?
--- linux-2.6.24.noarch.orig/include/linux/time.h +++ linux-2.6.24.noarch/include/linux/time.h @@ -169,7 +169,7 @@ extern struct timeval ns_to_timeval(cons * @a: pointer to timespec to be incremented * @ns: unsigned nanoseconds value to be added */ -static inline void timespec_add_ns(struct timespec *a, u64 ns) +static inline void timespec_add_ns(struct timespec *a, volatile u64 ns) { ns += a->tv_nsec; while(unlikely(ns >= NSEC_PER_SEC)) {
kernel@lists.fedoraproject.org