From: Al Viro <viro@ftp.linux.org.uk>
To: Kyle Moffett <mrmacman_g4@mac.com>
Cc: Hirokazu Takata <takata@linux-m32r.org>,
torvalds@osdl.org, linux-kernel@vger.kernel.org,
sam@ravnborg.org
Subject: Re: [PATCH] m32r: set CHECKFLAGS properly
Date: Wed, 28 Sep 2005 00:06:19 +0100 [thread overview]
Message-ID: <20050927230619.GV7992@ftp.linux.org.uk> (raw)
In-Reply-To: <3B320087-2A36-4106-AB85-0A1B626234A1@mac.com>
On Tue, Sep 27, 2005 at 02:37:09PM -0400, Kyle Moffett wrote:
> >And no, sparse (or any other C compiler) is not required to have
> >the same pile as gcc does.
>
> But when we're using sparse to check kernel sources, it should have a
> similar set to what the regular compiler (IE: gcc) has when building
> kernel sources.
Have you ever looked at that set of defines? Note that even with gcc
most of them are supposed to be only used in gcc headers. Most of
those are never used in the kernel code, and for a good reason. Only
two are actually used - stdarg.h and (for raid6 with CONFIG_ALTIVEC)
altivec.h. Guess what? The former doesn't use any of these defines
and in case of the latter the only define used would be a lie - sparse
does *not* handle -maltivec.
It gets even better when you get to defines that describe compiler capacities.
sparse, for example, does *not* support wchar_t et.al.; gcc does. Should
we lie about that support? Should sparse binary that kinda-sorta imitates
e.g. builtins of gcc 3.3 (and declares __GNUC... accordingly) pick bogus
ones from gcc4 you are using for build?
There are very few defines we really want out of that pile. "Take everything"
is nowhere near sanity, especially if you consider the differences between
gcc versions (and gcc builds, while we are at it).
next prev parent reply other threads:[~2005-09-27 23:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-26 5:18 [PATCH] m32r: set CHECKFLAGS properly Al Viro
2005-09-27 6:13 ` Hirokazu Takata
2005-09-27 7:10 ` Al Viro
2005-09-27 15:13 ` Kyle Moffett
2005-09-27 16:34 ` Al Viro
2005-09-27 17:31 ` Kyle Moffett
2005-09-27 17:55 ` Al Viro
2005-09-27 18:37 ` Kyle Moffett
2005-09-27 23:06 ` Al Viro [this message]
2005-09-27 20:02 ` Sam Ravnborg
2005-09-28 1:44 ` Al Viro
2005-09-27 6:23 ` Hirokazu Takata
2005-09-27 15:00 ` Linus Torvalds
2005-09-28 0:18 ` Al Viro
2005-09-28 10:04 ` Hirokazu Takata
2005-09-29 1:56 ` Al Viro
-- strict thread matches above, loose matches on Subject: below --
2005-09-26 5:19 Al Viro
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=20050927230619.GV7992@ftp.linux.org.uk \
--to=viro@ftp.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mrmacman_g4@mac.com \
--cc=sam@ravnborg.org \
--cc=takata@linux-m32r.org \
--cc=torvalds@osdl.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