From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4166 invoked by alias); 27 Sep 2013 09:43:54 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 4154 invoked by uid 89); 27 Sep 2013 09:43:53 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Sep 2013 09:43:53 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50,RP_MATCHES_RCVD,SPAM_SUBJECT autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8R9hpkw006896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 27 Sep 2013 05:43:51 -0400 Received: from zebedee.pink (ovpn-113-58.phx2.redhat.com [10.3.113.58]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8R9hoOh028298; Fri, 27 Sep 2013 05:43:50 -0400 Message-ID: <52455355.3020301@redhat.com> Date: Fri, 27 Sep 2013 09:43:00 -0000 From: Andrew Haley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: gcc-help@gcc.gnu.org Subject: Re: how to make gcc warn about arithmetic signed overflow References: <52409B07.1070002@redhat.com> <20130923180022.b06c9ae2.jklowden@schemamania.org> <5241D058.6000209@redhat.com> <20130925222958.63f91bc9.jklowden@schemamania.org> <20130926082941.GA31230@ypig.lip.ens-lyon.fr> <52444961.6030103@redhat.com> <20130926170232.GA8435@xvii.vinc17.org> <52446F22.3040205@redhat.com> <20130927075757.GA10027@ypig.lip.ens-lyon.fr> <52454087.3090208@redhat.com> <20130927092841.GB10027@ypig.lip.ens-lyon.fr> In-Reply-To: <20130927092841.GB10027@ypig.lip.ens-lyon.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00193.txt.bz2 On 09/27/2013 10:28 AM, Vincent Lefevre wrote: > On 2013-09-27 09:23:35 +0100, Andrew Haley wrote: >> On 09/27/2013 08:57 AM, Vincent Lefevre wrote: >>> On 2013-09-26 18:30:10 +0100, Andrew Haley wrote: >>>> On 09/26/2013 06:02 PM, Vincent Lefevre wrote: >>>>> On 2013-09-26 15:49:05 +0100, Andrew Haley wrote: >>>>>> On 09/26/2013 09:29 AM, Vincent Lefevre wrote: >>>>>>> On 2013-09-25 22:29:58 -0400, James K. Lowden wrote: >>>>>>>> You mean that a naïve rendering of the source code implies an overflow >>>>>>>> where none might exist in the actual emitted object code. 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. >>>>>>> >>>>>>> The converse is forbidden. >>>>>> >>>>>> You'll find it hard to justify that by any language in the standard. >>>>> >>>>> What do you mean? >>>> >>>> There is no reason why a compiler should not generate an overflow >>>> where none is written in the program, as long as it doesn't generate >>>> a different result. >>> >>> OK, I wouldn't call that an overflow, then. >> >> As far as the processor is concerned, what sets the overflow flag is >> an overflow. That's the context of this discussion. > > No, it isn't. If you regard the CPU overflow flag as a part of the > result, then the compiler is not allowed to generate overflows not > expressed in the source. Never. For instance, it would be really > wrong to get spurious crashes with -ftrapv just because gcc modified > the order of operations or just because the overflow flag has been > set with an unsigned operation (at the C level). Sure, but if -ftrapv is turned off, gcc can generate instructions that will overflow. I suspect that it would be very hard to get GCC to do this correctly in all cases when -ftrapv is turned on. > If you disregard the CPU overflow flag, then what the CPU does is > not regarded as an overflow. It is by the CPU. And it is by me. If you choose not to regard that as an overflow, I have no quarrel with you, but I will not agree. By the definition I am using, what sets the overflow flag is an overflow. > Note that Dave Allured asked whether there is a way to check the > CPU overflow flag on an example where there may be an overflow > *in the source*. Well, there probably isn't. As I have explained. Andrew.