From: Steve French <smfrench@austin.rr.com>
To: linux-kernel@vger.kernel.org
Subject: Compiling kernel with SuSE 8.2/gcc 3.3
Date: Wed, 11 Jun 2003 00:01:22 -0500 [thread overview]
Message-ID: <3EE6B7A2.3000606@austin.rr.com> (raw)
Stephan von Krawczynski <skraw@ithnet.com> writes:
> during tests with latest SuSE distro 8.2 compiling 2.4.21-pre6 showed a lot of
> "comparison between signed and unsigned" warnings. It looks like SuSE ships gcc
I also noticed lots of compiler warnings with gcc 3.3, now default in SuSE,
and cleaned up most of them for the cifs vfs but there are a few that just
look wrong for gcc to spit out warnings on. For example the following
local variable definition and the similar ones in the same file
(fs/cifs/inode.c):
__u64 uid = 0xFFFFFFFFFFFFFFFF;
generates a warning saying the value is too long for a long on
x86 SuSE 8.2 with gcc 3.3 - which makes no sense. Any value
above 0xFFFFFFFFF generates the same warning (intuitively
36 bits should fit in an unsigned 64 bit local variable).
Defining the literal with the UL suffix didn't seem to help - and I
rebelled against the solutions that work for this case ie casting
the local variable which is already __u64 to __u64 but that
presumably would work for those three, as would a (__u64)cast
of -1 which seems equally ugly). Unfortunately for the CIFS
Unix Extensions these values really are supposed to be 64 bit
on the wire (0xFFFFFFFFFFFFFFFF indicating ignore setting this value).
In the current version of the cifs vfs (http://cifs.bkbits.net/linux-2.5cifs)
the only other case that now generates compiler warnings (in this case
signed/unsigned compares) is the comparison of unsigned local variables
to the literal PAGE_CACHE_SIZE (which presumably is interpreted as
signed by the compiler).
Any idea what is going on in this weird gcc 3.3 behavior where it thinks
64 bits can't fit in a __u64 local variable?
next reply other threads:[~2003-06-11 4:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-11 5:01 Steve French [this message]
2003-06-11 11:20 ` Compiling kernel with SuSE 8.2/gcc 3.3 Richard B. Johnson
2003-06-11 13:59 ` Richard B. Johnson
2003-06-11 11:28 ` Matthias Andree
2003-06-11 16:12 ` Andreas Schwab
[not found] <3EE6B7A2.3000606@austin.rr.com.suse.lists.linux.kernel>
2003-06-11 8:01 ` Andi Kleen
2003-06-12 1:24 ` Steve French
2003-06-12 1:40 ` Andrew Morton
2003-06-12 2:17 ` Riley Williams
2003-06-12 2:00 ` Linus Torvalds
2003-06-12 12:52 ` Horst von Brand
[not found] <20030408134240.45cdad7e.skraw@ithnet.com.suse.lists.linux.kernel>
2003-04-08 13:14 ` Andi Kleen
[not found] <20030408115008$0cd2@gated-at.bofh.it>
2003-04-08 12:02 ` Arnd Bergmann
-- strict thread matches above, loose matches on Subject: below --
2003-04-08 11:42 Stephan von Krawczynski
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=3EE6B7A2.3000606@austin.rr.com \
--to=smfrench@austin.rr.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