From patchwork Wed Jul 16 02:23:50 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 4564201 Return-Path: X-Original-To: patchwork-linux-sparse@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 224C29F295 for ; Wed, 16 Jul 2014 02:23:56 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 51D12201BB for ; Wed, 16 Jul 2014 02:23:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6B725201B4 for ; Wed, 16 Jul 2014 02:23:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755324AbaGPCXy (ORCPT ); Tue, 15 Jul 2014 22:23:54 -0400 Received: from mail-qa0-f53.google.com ([209.85.216.53]:51878 "EHLO mail-qa0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754748AbaGPCXx (ORCPT ); Tue, 15 Jul 2014 22:23:53 -0400 Received: by mail-qa0-f53.google.com with SMTP id v10so196834qac.40 for ; Tue, 15 Jul 2014 19:23:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=otx5Y2k5o8xhmZRaPHr67dzLNMKOkpb29OffocApWw4=; b=jdzZA2oTcegqtqnyWSUZvZ2HA1ReskcIss/g2kPsrFejb955NLVve4phqOzgOEbvnm lOgXJSa1p06/TtchEqfOd1HlJqsBYdaJX7XJrjhTBD4gXH+QdAxcu2OKwCLIvs7au7lH KZCDlpzGFzQFrWDbvSRE+qsIqYgfqSqcUNO+/GvZqGeFdRkwdcSFVUgzryAvaHHIEPnz KFgWbdO68B4qQzrYX2q+SsN9m6ZZsbpppslbWsXABqsoAfUoVK5AJ2grMXK31Fd/MS9X XY2COIsDNc+jDCNBNR8HiWdR/0IV7bzfvxitwLlF2KTs8iD00esTYSJYUU4RwPxPI8Tl FGcQ== X-Gm-Message-State: ALoCoQn/LL3ztgiDzihNgoC3RulgX1Q23yiyw6Yi2AWfXFhkwb2u71DCPFRGt/Z4mPX7yqT+fBcS X-Received: by 10.224.96.137 with SMTP id h9mr36105206qan.96.1405477432779; Tue, 15 Jul 2014 19:23:52 -0700 (PDT) Received: from f20.localdomain (cpe-107-015-124-230.nc.res.rr.com. [107.15.124.230]) by mx.google.com with ESMTPSA id d3sm29082767qad.43.2014.07.15.19.23.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Jul 2014 19:23:52 -0700 (PDT) From: Jeff Layton X-Google-Original-From: Jeff Layton Date: Tue, 15 Jul 2014 22:23:50 -0400 To: Christopher Li Cc: Linux-Sparse , Pekka Enberg Subject: Re: [sparse PATCH RFC] Revert "Revert "sparse: Bump up sizeof(_Bool) to 8 bits"" Message-ID: <20140715222350.028a7bf6@f20.localdomain> In-Reply-To: References: <1405439200-27515-1-git-send-email-jlayton@primarydata.com> X-Mailer: Claws Mail 3.10.0 (GTK+ 2.24.22; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Sender: linux-sparse-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sparse@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, 15 Jul 2014 12:51:02 -0700 Christopher Li wrote: > On Tue, Jul 15, 2014 at 8:46 AM, Jeff Layton wrote: > > > > > > The problem here is that, at least with GCC on x86_64, a _Bool always > > seems to be end up being 8 bits (which makes sense -- how would you get > > a pointer to it otherwise?). If you declare and initialize an array like > > this: > > > > static _Bool boolarray[3] = { > > [0] = 1, > > [1] = 1, > > }; > > > > ...you get warnings like this (which are bogus): > > > > ./test.c:2:10: warning: Initializer entry defined twice > > ./test.c:3:10: also defined here > > > Right. The bug is in bits_to_bytes(). It round down instead of > round up. "bits_in_bool" is only a default value. It can be > reset to other value by the sparse application (sparse as > library). So the rest of the code still need to coupe with > it. > > How about fix bits_to_bytes() to round up: > > diff --git a/target.h b/target.h > index 1030c7c..140df3c 100644 > --- a/target.h > +++ b/target.h > @@ -49,7 +49,7 @@ extern int enum_alignment; > > static inline int bits_to_bytes(int bits) > { > - return bits >= 0 ? bits / bits_in_char : -1; > + return bits >= 0 ? (bits + bits_in_char - 1) / bits_in_char : -1; > } > This makes the bitfield.c validation test fail: TEST bitfield to integer promotion (bitfields.c) error: actual error text does not match expected error text. error: see bitfields.c.error.* for further investigation. Though I haven't looked in detail yet as to why it's failing. > > > > integer division, and that causes the above bogus warning. > > > > Reset it back to 8 bits, and add a validation test that creates the > > above array to ensure that we don't end up breaking it again. > > The rest of the change looks good. Thanks for the test case. > > My patch is not tested. If you are OK with it, submit a V2 > or I can fix the change for you. > > Thanks > > Chris --- bitfields.c.error.expected 2014-07-15 22:01:09.236942195 -0400 +++ bitfields.c.error.got 2014-07-15 22:01:09.237942176 -0400 @@ -0,0 +1,2 @@ +bitfields.c:16:19: warning: invalid access past the end of 'y' (0 1) +bitfields.c:16:19: warning: invalid access past the end of 'y' (0 1)