From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12904 invoked by alias); 1 Mar 2008 21:19:53 -0000 Received: (qmail 12887 invoked by uid 22791); 1 Mar 2008 21:19:52 -0000 X-Spam-Check-By: sourceware.org Received: from mail.enyo.de (HELO mail.enyo.de) (212.9.189.167) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 01 Mar 2008 21:19:26 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1JVZ6x-0006pR-Rc; Sat, 01 Mar 2008 22:19:16 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1JVZ6x-0002Ui-4n; Sat, 01 Mar 2008 22:19:15 +0100 From: Florian Weimer To: Robert Dewar Cc: Richard Guenther , "Joseph S. Myers" , Mark Mitchell , gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: [PATCH][4.3] Deprecate -ftrapv References: <47C89DB1.6030200@codesourcery.com> <47C8AB88.10503@codesourcery.com> <47C95C35.2070908@adacore.com> <47C962A4.9020208@adacore.com> <874pbq1aso.fsf@mid.deneb.enyo.de> <47C9B864.8020608@adacore.com> Date: Sat, 01 Mar 2008 21:19:00 -0000 In-Reply-To: <47C9B864.8020608@adacore.com> (Robert Dewar's message of "Sat, 01 Mar 2008 15:11:16 -0500") Message-ID: <87skzajg6k.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-03/txt/msg00069.txt.bz2 * Robert Dewar: > Florian Weimer wrote: >> * Robert Dewar: >> >>> So here's exactly what happens now in Ada >>> >>> 1. If -gnato is not set (no overflow checking) >>> >>> In this case, the situation is exactly the same as C, and the front end >>> ignores the possibility of overflow. >> >> It's C in -fwrapv mode, isn't it? (Otherwise, you can't really get the >> other constraint checks to work, including bounds checking for array >> access.) > > No, it is exactly C, if an arithmetic operation causes overflow > and you do not have -gnato set, and overflow occurs, the program > execution is erroneous. I reread the last para above more than once > but cannot guess what you are getting. Are we talking about the Ada semantics or GNAT without -gnato? In the latter case, the documentation disagrees with you: The reason that we distinguish overflow checking from other kinds of range constraint checking is that a failure of an overflow check can generate an incorrect value, but cannot cause erroneous behavior. This is unlike the situation with a constraint check on an array subscript, where failure to perform the check can result in random memory description, or the range check on a case statement, where failure to perform the check can cause a wild jump. And to avoid erroneous execution on integer overflow, I think you have to specify the equivalent -fwrapv (otherwise, the middle end might do nasty things to your range checks). > Why is it surprising, if you suppress overflow checks you are saying > that overflow does not occur, just as you say this for *any* C > program. > > I don't understand the surprise or the concern here, can you > elucidate? The documentation says something else, that's why it's surprising. 8-)