From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: linux-sparse@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Bart Van Assche <bvanassche@acm.org>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Subject: [PATCH 0/5] allow -1 and compares in bitwise types
Date: Mon, 27 Jun 2022 21:05:35 +0200 [thread overview]
Message-ID: <20220627190540.13358-1-luc.vanoostenryck@gmail.com> (raw)
In-Reply-To: <CAHk-=wj8gM8q04v2jS5JGjEdoE2d+B4_nm74xrFjZ77f9YRsbA@mail.gmail.com>
Allow using -1 and compare operators with bitwise types
This series is an experiment for allowing constants like
-1 or ~0 with bitwise types, as well as using compares
on them.
the motivation for allowing this is to avoid useless casts
and warnings on using some generic macros on bitwise types.
The case of interest here is:
#define is_signed_type(T) (((T)(-1)) < (T)1)
for which Sparse reports four warnings when 'T' is a bitwise
type. Two of these warnings can be suppressed by using
'__force' in the casts. But the other two can't be worked
around because explicitly reject using any constants other
than 0 with bitwise type.
The changes in the series allow to use the following testcase
without any warnings:
#define __bitwise __attribute__((bitwise))
typedef signed int __bitwise s;
typedef unsigned int __bitwise u;
#define is_signed_type(type) (((type)-1) <= 0)
int fs(void) { return ((s)-1) <= 0; }
int fu(void) { return ((u)-1) <= 0; }
and result in a modest but significant decrease in the number
of warnings issued by sparse (x86 {def,all}config):
- 2736 2735 cast to restricted type
+ 774 792 cast truncates bits from constant value
- 3183 3152 incorrect type in assignment (different base types)
- 162 159 incorrect type in initializer (different base types)
- 789 661 restricted type degrades to integer
- 13002 12857 Total
@Linus,
This seems to work correctly and I think it correspond to
what you wished (maybe modulo this 'early constant expansion'
I added) and I think that accepting the -1/all-ones is fine.
OTOH, I don't think we can allow the compares because they
don't make any sense for the 'endian' types. Surely we want
to catch things like:
typedef unsigned int __bitwise __be32;
__be32 x, y;
...
... (x < y)
@Bart,
Is there a good reason why the macro compares against 1 and
not against 0? Is it just because of -Wtype-limits? If so,
is it possible to use '<= 0' like here above?
The series is available for review and testing at:
https://git.kernel.org/pub/scm/devel/sparse/sparse.git bitwise-ones
Luc Van Oostenryck (5):
bitwise: add testcases
bitwise: accept all ones as non-restricted value
bitwise: allow compares for bitwise types
bitwise: do not remove the signedness of bitwise types
bitwise: early expansion of simple constants
evaluate.c | 52 +++++++++++++++++++++++++++++++-
parse.c | 1 -
show-parse.c | 2 +-
validation/bitwise-cast.c | 26 ++++++++++++++++
validation/bitwise-cmp.c | 31 +++++++++++++++++++
validation/bitwise-is-signed.c | 21 +++++++++++++
validation/linear/bitwise-cmps.c | 17 +++++++++++
validation/linear/bitwise-cmpu.c | 17 +++++++++++
8 files changed, 164 insertions(+), 3 deletions(-)
create mode 100644 validation/bitwise-cmp.c
create mode 100644 validation/bitwise-is-signed.c
create mode 100644 validation/linear/bitwise-cmps.c
create mode 100644 validation/linear/bitwise-cmpu.c
--
2.36.1
next prev parent reply other threads:[~2022-06-27 19:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220623180528.3595304-1-bvanassche@acm.org>
[not found] ` <20220623180528.3595304-52-bvanassche@acm.org>
[not found] ` <20220624045613.GA4505@lst.de>
[not found] ` <aa044f61-46f0-5f21-9b17-a1bb1ff9c471@acm.org>
[not found] ` <20220625092349.GA23530@lst.de>
[not found] ` <3eed7994-8de2-324d-c373-b6f4289a2734@acm.org>
2022-06-26 9:58 ` [PATCH 51/51] fs/zonefs: Fix sparse warnings in tracing code Luc Van Oostenryck
2022-06-26 15:42 ` Bart Van Assche
2022-06-26 16:24 ` Luc Van Oostenryck
2022-06-26 16:33 ` Linus Torvalds
2022-06-26 16:50 ` Linus Torvalds
2022-06-26 20:10 ` Luc Van Oostenryck
2022-06-26 19:44 ` Luc Van Oostenryck
2022-06-27 19:05 ` Luc Van Oostenryck [this message]
2022-06-27 19:05 ` [PATCH 1/5] bitwise: add testcases Luc Van Oostenryck
2022-06-27 19:05 ` [PATCH 2/5] bitwise: accept all ones as non-restricted value Luc Van Oostenryck
2022-06-27 23:32 ` Ramsay Jones
2022-06-27 19:05 ` [PATCH 3/5] bitwise: allow compares for bitwise types Luc Van Oostenryck
2022-06-27 19:20 ` Linus Torvalds
2022-06-27 23:34 ` Ramsay Jones
2022-06-27 19:05 ` [PATCH 4/5] bitwise: do not remove the signedness of " Luc Van Oostenryck
2022-06-27 19:05 ` [PATCH 5/5] bitwise: early expansion of simple constants Luc Van Oostenryck
2022-06-27 19:14 ` [PATCH 0/5] allow -1 and compares in bitwise types Linus Torvalds
2022-06-27 19:15 ` Bart Van Assche
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=20220627190540.13358-1-luc.vanoostenryck@gmail.com \
--to=luc.vanoostenryck@gmail.com \
--cc=bvanassche@acm.org \
--cc=linux-sparse@vger.kernel.org \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).