linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).