public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <iant@google.com>
To: Agner Fog <agner@agner.org>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Is it OK that gcc optimizes away overflow check?
Date: Tue, 26 Jul 2011 14:44:00 -0000	[thread overview]
Message-ID: <mcrhb69m7b5.fsf@coign.corp.google.com> (raw)
In-Reply-To: <4E2E6CC6.3040106@agner.org> (Agner Fog's message of "Tue, 26 Jul	2011 09:29:10 +0200")

Agner Fog <agner@agner.org> writes:

> Now, imagine doing something like this before every +, -, *, /,
> etc. in your code! If this is necessary then the C/C++ language is
> useless. We are in deep trouble now and we desperately need a better
> solution.

Nobody would suggest using that construction before every arithmetic
operation.  One would only suggest using it before an operation which
may overflow.

You are writing as though wrapping overflow is always the right thing to
do, but that is false.  In code written by a naive programmer, wrapping
on overflow will cause problems just as undefined overflow will.


> Your suggestion to use __attribute__ ((optimize
> ("-fno-strict-overflow"))); was an excellent idea. Unfortunately it
> doesn't work. The compiler says: warning: âoptimizeâ attribute
> directive ignored.

When I compile this test case with current gcc mainline

#include <stdlib.h>
int f (int) __attribute__ ((optimize ("-fno-strict-overflow")));
int f (int i) { return abs (i) < 0; }

the comparison is not optimized away.  So I think that the attribute
does work in current gcc.


> We need to be constructive here. We want the optimizations, but we
> also want to check if the optimizations go wrong. I think the compiler
> should be able to generate warnings for every unsafe optimization,
> especially when removing a branch. The compiler generates a warning
> when optimizing away  if (a+5 < a)  but not when optimizing away  if
> (abs(a)<0).

When I compile this test case

#include <stdlib.h>
int f (int i) { return abs (i) < 0; }

with -O2 -Wstrict-overflow I see this warning:

foo.c:2: warning: assuming signed overflow does not occur when simplifying comparison of absolute value and zero

So I think the compiler does warn about optimizing that comparison away.

Ian

  parent reply	other threads:[~2011-07-26 14:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-23 20:14 Agner Fog
2011-07-23 21:06 ` Jeffrey Walton
2011-07-25  6:07   ` Ian Lance Taylor
2011-07-25  6:04 ` Ian Lance Taylor
2011-07-25  8:32   ` Agner Fog
2011-07-25 17:18     ` me22
2011-07-25 17:50     ` Ian Lance Taylor
2011-07-26  9:39   ` Agner Fog
2011-07-26 10:35     ` Andrew Haley
2011-07-26 17:31       ` Andrew Haley
2011-07-27 15:03         ` Agner Fog
2011-07-26 14:55     ` Jeffrey Walton
     [not found]   ` <4E2E6CC6.3040106@agner.org>
2011-07-26 14:44     ` Ian Lance Taylor [this message]
2011-07-26 16:24       ` Agner Fog
2011-07-26 18:17         ` Ian Lance Taylor
2011-07-25  9:43 ` Andrew Haley
2011-07-25 15:38   ` Agner Fog
2011-07-25 16:22     ` Andrew Haley
2011-07-30 23:30       ` Vincent Lefevre
2011-08-01  8:59         ` Andrew Haley

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=mcrhb69m7b5.fsf@coign.corp.google.com \
    --to=iant@google.com \
    --cc=agner@agner.org \
    --cc=gcc-help@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).