public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Daniel Berlin <dberlin@dberlin.org>
To: Gabriel Dos Reis <gdr@integrable-solutions.net>
Cc: Joe Buck <Joe.Buck@synopsys.COM>,
	Andrew Pinski <pinskia@physics.uc.edu>,
	 'gcc mailing list' <gcc@gcc.gnu.org>
Subject: Re: Should GCC publish a general rule/warning due to it's default presumption of undefined signed integer overflow semantics?
Date: Fri, 01 Jul 2005 03:16:00 -0000	[thread overview]
Message-ID: <1120187757.17986.14.camel@linux-009002243055> (raw)
In-Reply-To: <m3y88r484c.fsf@uniton.integrable-solutions.net>

On Fri, 2005-07-01 at 03:39 +0200, Gabriel Dos Reis wrote:
> Joe Buck <Joe.Buck@synopsys.COM> writes:
> 
> | On Thu, Jun 30, 2005 at 09:02:48PM -0400, Andrew Pinski wrote:
> | > But the reason question is why make it an undefined behavior instead of
> | > an implementation defined?  This would have made it clearer instead of
> | > allowing the compiler not document what happens.  Or is C++
> | > just following C here?  In which case it might be better to ask the C
> | > committee why it was done this way and real definition of undefined for
> | > this case?
> | 
> | I already showed you the answer: loop optimization works better if you
> | can ignore overflow.
> 
> There are various ways to work within "loop optimization" assumptions.

Gaby, if you have plans to do what nobody else has had any real luck
doing for 10 years in compilers in any practical way, which is proving
the iteration count of loops in the presence of overflow, please share.

It's possible, but all methods i'm aware that even attempt it are
incredibly expensive (exponential) in every case.

This isn't about SPEC numbers, it's about every single piece of
Numerical C, Fortran, and C++ i've ever seen.


--Dan

  reply	other threads:[~2005-07-01  3:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-30 19:15 Paul Schlie
2005-06-30 20:08 ` Paul Schlie
2005-06-30 22:06 ` Joe Buck
2005-06-30 22:26   ` Gabriel Dos Reis
2005-06-30 23:25     ` Joe Buck
2005-07-01  0:49       ` Gabriel Dos Reis
2005-07-01  1:03         ` Andrew Pinski
2005-07-01  1:23           ` Gabriel Dos Reis
2005-07-01  1:25           ` Joe Buck
2005-07-01  1:40             ` Gabriel Dos Reis
2005-07-01  3:16               ` Daniel Berlin [this message]
2005-07-01  4:07                 ` Gabriel Dos Reis
2005-07-01  4:15                   ` Andrew Pinski
2005-07-01  4:58                     ` Gabriel Dos Reis
2005-07-01  4:53                       ` Andrew Pinski
2005-07-01  5:02                         ` Gabriel Dos Reis
2005-07-02 16:51                   ` Robert Dewar
2005-07-02 19:07                     ` Gabriel Dos Reis
2005-07-02 23:15                       ` Robert Dewar
2005-07-02 23:28                         ` Joe Buck
2005-07-03  0:20                           ` Gabriel Dos Reis
2005-07-03  0:16                         ` Gabriel Dos Reis
2005-07-02 16:47           ` Robert Dewar
2005-07-02 16:45         ` Robert Dewar
2005-07-01  1:04       ` Paul Schlie
2005-07-02 16:48         ` Robert Dewar
2005-07-01  1:35       ` Paul Schlie

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=1120187757.17986.14.camel@linux-009002243055 \
    --to=dberlin@dberlin.org \
    --cc=Joe.Buck@synopsys.COM \
    --cc=gcc@gcc.gnu.org \
    --cc=gdr@integrable-solutions.net \
    --cc=pinskia@physics.uc.edu \
    /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).