From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Marko Kreen" Subject: Re: confusing shift warning Date: Fri, 25 Apr 2008 11:34:58 +0300 Message-ID: References: <33544769883882222@unknownmsgid> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from nf-out-0910.google.com ([64.233.182.185]:10715 "EHLO nf-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756936AbYDYIfF (ORCPT ); Fri, 25 Apr 2008 04:35:05 -0400 Received: by nf-out-0910.google.com with SMTP id g13so1405670nfb.21 for ; Fri, 25 Apr 2008 01:34:58 -0700 (PDT) In-Reply-To: <33544769883882222@unknownmsgid> Content-Disposition: inline Sender: linux-sparse-owner@vger.kernel.org List-Id: linux-sparse@vger.kernel.org To: Pavel Roskin Cc: linux-sparse@vger.kernel.org On 4/25/08, Pavel Roskin wrote: > Quoting Marko Kreen : > > > > Platform: x64_64 linux, uint64_t -> unsigned long > > Sparse: today's git (6dcc36a) > > > ... > > > Guess - somewhere is hardwired that "long" == "32-bit"? > > > > Of course not. But -m64 should be specified to enable 64-bit type sizes. > > > > For reference: > > $ cgcc -v -c test.c > > sparse -v -c test.c -Dx86_64=1 -D__x86_64=1 -D__x86_64__=1 > > > ... > > cgcc fails to add -m64. It must be a bug in cgcc. This would not produce > the warning: > > cgcc -m64 -no-compile Test.c Ok, that somewhat explains it. But: } elsif ($spec eq 'x86_64') { return (' -Dx86_64=1 -D__x86_64=1 -D__x86_64__=1' . &integer_types (8, 16, 32, $m32 ? 32 : 64, 64) . &float_types (1, 1, 33, [24,8], [53,11], [113,15]) . &define_size_t ($m32 ? "unsigned int" : "long unsigned int")); It seems that cgcc defaults to 64-bit on x86_64, but sparse to 32-bit. Isn't it sparse bug then? Shouldnt it follow platform defaults? -- marko