From: torvalds@transmeta.com (Linus Torvalds)
To: linux-kernel@vger.kernel.org
Subject: Re: 2.4.15-pre4 compile problem
Date: Mon, 12 Nov 2001 20:27:39 +0000 (UTC) [thread overview]
Message-ID: <9spbbr$1qi$1@penguin.transmeta.com> (raw)
In-Reply-To: <200111121939.fACJdX309798@danapple.com>
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
next prev parent reply other threads:[~2001-11-12 20:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-12 19:39 2.4.15-pre4 compile problem Daniel I. Applebaum
2001-11-12 20:22 ` Daniel I. Applebaum
2001-11-12 20:27 ` Linus Torvalds [this message]
2001-11-12 20:34 ` Slo Mo Snail
2001-11-12 20:45 ` Robert Love
-- strict thread matches above, loose matches on Subject: below --
2001-11-12 20:27 Wayne.Brown
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='9spbbr$1qi$1@penguin.transmeta.com' \
--to=torvalds@transmeta.com \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox