Messages in this thread |  | | From | (Linus Torvalds) | Subject | Re: 2.4.15-pre4 compile problem | Date | Mon, 12 Nov 2001 20:27:39 +0000 (UTC) |
| |
In article <200111121939.fACJdX309798@danapple.com>, Daniel I. Applebaum <kernel@danapple.com> wrote: > >While compiling 2.4.15-pre4: >+++++++++++++++ >gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o setup.o setup.c >setup.c: In function `c_start': >setup.c:2791: subscripted value is neither array nor pointer
Ugh. That's because a buggy #define on UP in x86.
It should be trivially fixed by changing include/asm-i386/processor.h:
#define cpu_data &boot_cpu_data
to
#define cpu_data (&boot_cpu_data)
in order to get the right parsing order for all users of cpu_data. Ie just add the parenthesis around the thing.
Oh, well. "Always put parentesis around define-expands" is a really really good rule. Along with "Always put parenthesis around the argument expansion too".
Oh, and cleaning up the particular offending user will hide the problem too, if you just use
cpu_data+*pos
instead of using
&cpu_data[*pos]
in arch/i386/kernel/setup.c: c_start(). Which is cleaner and simpler anyway, and which is defined by C to be exactly the same thing (as long as "cpu_data" behaves like a real array, not a broken #define that depends on operator precedence around it).
I'll do both in my tree. Thanks,
Linus - 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/
|  |