public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew Haley <aph@redhat.com>
To: "James K. Lowden" <jklowden@schemamania.org>
Cc: gcc-help@gcc.gnu.org
Subject: Re: how to make gcc warn about arithmetic signed overflow
Date: Thu, 26 Sep 2013 17:41:00 -0000	[thread overview]
Message-ID: <524471C0.2010701@redhat.com> (raw)
In-Reply-To: <20130925222958.63f91bc9.jklowden@schemamania.org>

On 09/26/2013 03:29 AM, James K. Lowden wrote:
> On Tue, 24 Sep 2013 18:48:08 +0100
> Andrew Haley <aph@redhat.com> wrote:
> 
>>> Regardless of optimization, the CPU, not
>>> the compiler, executes the ADD or MUL operation, or whatever, and
>>> sets or does not set the overflow bit accordingly, right?  Why
>>> can't the compiler generate code that senses that, and raises a
>>> runtime error?
>>
>> Because the compiler does a lot of rewriting.  There is not a one-to-
>> one mapping between operations in your source program and
>> instructions.  An operation might occur in your program but not in the
>> object code.  For example, say you do this:
>>
>>    int n = m + BIG_NUMBER;
>>    return n - BIG_NUMBER;
>>
>> There is an overflow in your source, but not in the object code.  So
>> no trap will occur.
> 
> I thought that's what you meant.  I was confused by "in your source"
> because of course source code doesn't overflow.

Well, overflows occur in terms of the virtual machine in which
standard C is specified.  So, IMO, it's not unreasonable to say that
the overflows are there in your source.

> You mean that a naïve rendering of the source code implies an
> overflow where none might exist in the actual emitted object code.

No, I don't.  If, say, you add two ints together and the sum is
greater than the maximum size, then a overflow occurs.  Whether this
overflow actually causes a machine overflow is another matter.

> And, presumably, the converse: that even if the source is written
> such that there logically can't be an overflow, the compiler might
> render object code that does.
> 
> As far as I'm concerned, that's neither here nor there.  When the
> compiler is done, there is object code that does execute on a real
> CPU and does -- on some architectures -- set an overflow bit in the
> status word for overflowing integer operations.

And what use would that be?  I can't think of any.  You'd have
erroneous programs that do overflow still not raising the overflow
flag because GCC helpfully removes the overflowing code.  It can do
that.  So you'd still have erroneous results.

Andrew.

  parent reply	other threads:[~2013-09-26 17:41 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-21 16:45 wempwer
2013-09-21 17:24 ` Jonathan Wakely
2013-09-21 17:41   ` wempwer
2013-09-21 18:30     ` Jonathan Wakely
2013-09-21 18:50       ` wempwer
2013-09-21 19:55         ` Jędrzej Dudkiewicz
2013-09-21 20:16           ` wempwer
2013-09-21 20:52             ` Jędrzej Dudkiewicz
2013-09-21 21:07               ` wempwer
2013-09-23  4:04       ` James K. Lowden
2013-09-23  7:55         ` Jonathan Wakely
2013-09-23 15:47           ` James K. Lowden
2013-09-23 21:50             ` Jonathan Wakely
2013-09-23 22:44               ` James K. Lowden
2013-09-23 23:20                 ` Jonathan Wakely
2013-09-23 19:38         ` Dave Allured - NOAA Affiliate
2013-09-23 19:43           ` Oleg Endo
2013-09-23 20:37             ` Dave Allured - NOAA Affiliate
2013-09-23 19:48           ` Andrew Haley
2013-09-23 22:00             ` James K. Lowden
2013-09-24 17:48               ` Andrew Haley
2013-09-26  2:30                 ` James K. Lowden
2013-09-26  8:29                   ` Vincent Lefevre
2013-09-26 14:49                     ` Andrew Haley
2013-09-26 17:03                       ` Vincent Lefevre
2013-09-26 18:19                         ` Andrew Haley
2013-09-27  7:58                           ` Vincent Lefevre
2013-09-27  8:23                             ` Andrew Haley
2013-09-27  9:28                               ` Vincent Lefevre
2013-09-27  9:43                                 ` Andrew Haley
2013-09-26 17:41                   ` Andrew Haley [this message]
2013-09-24  7:42           ` Brian Drummond
2013-09-21 17:53   ` Marc Glisse
2013-09-21 18:09     ` wempwer
2013-09-21 18:27       ` Jonathan Wakely
2013-09-21 19:32         ` wempwer
2013-09-22 15:52           ` Jonathan Wakely
2013-09-23 13:04           ` David Brown
2013-09-21 17:36 ` Brian Drummond
2013-09-21 17:45   ` wempwer

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=524471C0.2010701@redhat.com \
    --to=aph@redhat.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=jklowden@schemamania.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).