From: Dan Carpenter <dan.carpenter@oracle.com>
To: Steve French <smfrench@gmail.com>,
Nicolai Stange <nicstange@gmail.com>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
Chris Li <christ.li@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, linux-sparse@vger.kernel.org
Subject: Re: checkpatch warnings in sched.h
Date: Fri, 20 Sep 2019 13:25:35 +0300 [thread overview]
Message-ID: <20190920102535.GA25547@kadam> (raw)
In-Reply-To: <CAH2r5mu1+muust_HA8oOWjYSmH6cLZA-d7pRzGJJsHauoDdJdQ@mail.gmail.com>
On Fri, Sep 20, 2019 at 02:34:46AM -0500, Steve French wrote:
> Any hints to get rid of the noisy warnings in sched.h that make it
> hard to spot real warnings:
>
> /include/linux/sched.h:609:43: error: bad integer constant expression
> /include/linux/sched.h:609:73: error: invalid named zero-width bitfield `value'
>
This is a bug in Sparse and it's way worse than you think. It actually
disables the real Sparse warnings because now Sparse thinks it has
encountered a parse error. I think we should just ifdef out that Sparse
code.
The problem is that if you have code like:
1 ? 1 :__bits_per()
GCC treats that as a compile constant but Sparse says that it's not
because all three elements of the conditional statement have to be
constant. See the code in evaluate_conditional_expression(). The
complication is that Sparse sets the constant flags before calls
expand_expression() to see what the condition part of the statement is
so the code needs to shuffled around to set the constant bits to match
GCC.
I'm going to #ifdef this out for Smatch later today but someone needs
to do the same thing in Sparse because right now no one can check for
endian bugs until this gets fixed. It's been broken for a month so
we'll probably get a flood of patches marking functions as static once
we patch this and people start seeing that warning again.
regards,
dan carpenter
parent reply other threads:[~2019-09-20 10:25 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <CAH2r5mu1+muust_HA8oOWjYSmH6cLZA-d7pRzGJJsHauoDdJdQ@mail.gmail.com>]
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=20190920102535.GA25547@kadam \
--to=dan.carpenter@oracle.com \
--cc=christ.li@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sparse@vger.kernel.org \
--cc=luc.vanoostenryck@gmail.com \
--cc=nicstange@gmail.com \
--cc=smfrench@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).