From: Miika <nykseli@protonmail.com>
To: Yair Lenga <yair.lenga@gmail.com>
Cc: gcc@gcc.gnu.org
Subject: [RFC] Support for nonzero attribute
Date: Sat, 04 Jun 2022 11:55:02 +0000 [thread overview]
Message-ID: <frxPLg2g6nUhRExsXL-1TccEZWJzj-8LxYNTRdZ4aN8FOk9G73dTQOfwInGHn9e6j3zldrij_F2STOcY5Fv4-qIykTGtPL6m1QM8n91hvQ4=@protonmail.com> (raw)
In-Reply-To: <CAK3_KpO=VFWmB0AdtNOqNrVjv29pU4jxNgfko14qTWHzYBxivw@mail.gmail.com>
On Saturday, June 4th, 2022 at 1:26 PM, Yair Lenga via Gcc <gcc@gcc.gnu.org> wrote:
> The specific non-zero constraint is a specific implementation of the range
> operator (with some exception see below). Wanted to suggest going for
> more ambitious goal: add min and max attributes to (integer) types and
> variables. This will address the specific case of non-zero, but has a lot
> of potential to be built upon: can be used for compile time testing, run
> time parameter checking, storage optimization (similar to packed), run time
> optimization (e.g. eliminating runtime tests), .... Also expected range
> information can have a positive impact on code safety/validation.
I like this idea a lot too. I'll definitely look into adding a "range"
variable attribute after the work with function attributes is done.
I'm not that familiar with GCC's optimizer but basic compiler warnings
should be fairly easy to implement.
Miika
next prev parent reply other threads:[~2022-06-04 11:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.2312.1654300374.1672222.gcc@gcc.gnu.org>
2022-06-04 10:26 ` Yair Lenga
2022-06-04 11:55 ` Miika [this message]
2022-06-04 21:29 ` Yair Lenga
2022-06-13 9:49 ` Richard Biener
2022-06-03 16:34 Miika
2022-06-03 16:45 ` Jakub Jelinek
2022-06-04 11:25 ` Miika
2022-06-05 20:09 ` Miika
2022-06-06 18:42 ` Ben Boeckel
2022-06-07 19:39 ` Miika
2022-06-07 19:44 ` Jonathan Wakely
2022-06-07 19:46 ` Jonathan Wakely
2022-06-07 19:56 ` Miika
2022-06-08 17:42 ` Eric Gallager
2022-06-08 20:59 ` Miika
2022-06-09 4:36 ` Eric Gallager
2022-06-09 18:06 ` Miika
2022-06-12 4:25 ` Prathamesh Kulkarni
2022-06-13 12:55 ` Miika
2022-06-13 16:02 ` Martin Sebor
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='frxPLg2g6nUhRExsXL-1TccEZWJzj-8LxYNTRdZ4aN8FOk9G73dTQOfwInGHn9e6j3zldrij_F2STOcY5Fv4-qIykTGtPL6m1QM8n91hvQ4=@protonmail.com' \
--to=nykseli@protonmail.com \
--cc=gcc@gcc.gnu.org \
--cc=yair.lenga@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 read-only IMAP folder(s) and NNTP newsgroup(s).