From: Paul Schlie <schlie@comcast.net>
To: Paolo Bonzini <bonzini@gnu.org>, <gcc@gcc.gnu.org>
Subject: Re: basic VRP min/max range overflow question
Date: Fri, 17 Jun 2005 12:00:00 -0000 [thread overview]
Message-ID: <BED82DB3.A845%schlie@comcast.net> (raw)
> Paolo Bonsini wrote:
>> Upon a potential integer overflow of either it's min or max range,
>> shouldn't the result be set to [min:type-min-value, max:type-max-value],
>> without the necessity of any further designations?
>
> No.
>
> [10, INT_MAX] + [ 1, 1 ] == [ 11, INT_MAX ] because of the famous signed
> int overflow definition in the C standard.
>
> [10U, UINT_MAX] + [ 1U, 1U ] == ~[ 1U, 10U ]
??? Do you mean:
H.2.2 Integer types
[#1] The signed C integer types int, long, long long and the
corresponding unsigned types are compatible with LIA-1. If an
implementation adds support for the LIA-1 exceptional values
integer_overflow and undefined, then those types are LIA-1
conformant types. C's unsigned integer types are "modulo" in the
LIA-1 sense in that overflows or out-of-bounds results silently
wrap. An implementation that defines signed integer types as also
being modulo need not detect integer overflow, in which case,
only integer divide-by-zero need be detected.
Where in combination with:
5.1.2.3 Program execution
Examples 2. In executing the fragment
char c1, c2;
/* ... */
c1 = c1 + c2;
the ``integer promotions'' require that the abstract
machine promote the value of each variable to int size
and then add the two ints and truncate the sum.
Provided the addition of two chars can be done without
overflow, or with overflow wrapping silently to
produce the correct result, the actual execution need
only produce the same result, possibly omitting the
promotions.
It seems pretty clear given that for all practical purposes all typical
machines do silently wrap integer overflow, they all correspondingly yield:
[10, INT_MAX] + [ 1, 1 ] == [INT_MIN, INT_MAX ]
[10U, UINT_MAX] + [ 1U, 1U ] == [UINT_MIN, UINT_MAX]
or more generally: [<INTEGER-TYPE>_MIN, <INTEGER-TYPE>_MAX] upon overflow.
next reply other threads:[~2005-06-17 12:00 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-17 12:00 Paul Schlie [this message]
2005-06-17 12:09 ` Paolo Bonzini
2005-06-17 18:29 ` Paul Schlie
2005-06-17 22:09 ` Paolo Bonzini
2005-06-17 22:48 ` Diego Novillo
2005-06-18 0:20 ` Paul Schlie
2005-06-18 0:23 ` Andrew Pinski
2005-06-18 0:59 ` Paul Schlie
2005-06-18 1:10 ` Dale Johannesen
2005-06-18 4:09 ` Mike Stump
[not found] ` <25364524.1119085038744.JavaMail.root@dtm1eusosrv72.dtm.ops.eu.uu.net>
2005-06-18 11:47 ` Toon Moene
2005-06-18 2:02 ` Robert Dewar
-- strict thread matches above, loose matches on Subject: below --
2005-06-18 14:15 Paul Schlie
2005-06-18 16:19 ` Joseph S. Myers
2005-06-18 17:44 ` Paul Schlie
2005-06-18 18:05 ` Paul Schlie
2005-06-18 18:21 ` Joseph S. Myers
2005-06-18 18:50 ` Paul Schlie
2005-06-18 19:57 ` Joseph S. Myers
2005-06-18 21:01 ` Florian Weimer
2005-06-19 10:18 ` Kai Henningsen
2005-06-20 22:20 ` Mike Stump
2005-06-18 19:16 ` Paul Schlie
2005-06-18 21:26 ` Robert Dewar
2005-06-19 18:23 ` Paul Schlie
2005-06-20 2:44 ` Robert Dewar
2005-06-20 5:55 ` Paul Schlie
2005-06-20 10:14 ` Michael Veksler
2005-06-20 11:04 ` Paul Schlie
2005-06-20 11:32 ` Robert Dewar
2005-06-20 12:08 ` Paul Schlie
2005-06-20 12:39 ` Robert Dewar
2005-06-20 13:01 ` Paul Schlie
2005-06-20 13:14 ` Robert Dewar
2005-06-20 12:23 ` Michael Veksler
2005-06-20 12:46 ` Robert Dewar
2005-06-20 10:43 ` Robert Dewar
2005-06-20 10:54 ` Robert Dewar
2005-06-20 11:26 ` Paul Schlie
2005-06-20 11:34 ` Robert Dewar
2005-06-20 12:09 ` Paul Schlie
2005-06-20 11:14 ` Paul Schlie
2005-06-20 12:53 ` Michael Veksler
2005-06-20 12:59 ` Robert Dewar
2005-06-20 13:09 ` Paul Schlie
2005-06-20 13:17 ` Robert Dewar
2005-06-20 14:54 ` Michael Veksler
2005-06-20 18:01 ` Paul Schlie
2005-06-18 18:08 ` Joseph S. Myers
2005-06-18 21:08 ` Robert Dewar
2005-06-19 10:18 ` Kai Henningsen
2005-06-19 10:49 ` Robert Dewar
2005-06-20 13:22 ` Sebastian Pop
2005-06-20 18:10 ` DJ Delorie
2005-07-13 7:57 ` Sebastian Pop
2005-07-13 15:18 ` DJ Delorie
2005-06-21 15:21 ` Robert Dewar
2005-07-18 16:34 ` Sebastian Pop
2005-07-18 16:44 ` Robert Dewar
2005-07-19 6:44 ` Sebastian Pop
2005-07-19 7:07 ` Michael Veksler
2005-07-19 9:55 ` Sebastian Pop
2005-07-19 10:22 ` Michael Veksler
2005-06-20 19:53 ` Kai Henningsen
2005-06-18 20:55 ` Robert Dewar
2005-06-18 22:45 ` Tristan Wibberley
2005-06-20 21:47 ` Mike Stump
2005-06-17 4:28 Paul Schlie
2005-06-17 7:03 ` Paolo Bonzini
2005-06-17 12:28 ` Diego Novillo
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=BED82DB3.A845%schlie@comcast.net \
--to=schlie@comcast.net \
--cc=bonzini@gnu.org \
--cc=gcc@gcc.gnu.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 read-only IMAP folder(s) and NNTP newsgroup(s).