From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17815 invoked by alias); 26 Jul 2011 14:44:05 -0000 Received: (qmail 17805 invoked by uid 22791); 26 Jul 2011 14:44:04 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 26 Jul 2011 14:43:43 +0000 Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p6QEhgS3006749 for ; Tue, 26 Jul 2011 07:43:42 -0700 Received: from gwb20 (gwb20.prod.google.com [10.200.2.20]) by hpaq5.eem.corp.google.com with ESMTP id p6QEglpU023408 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 26 Jul 2011 07:43:40 -0700 Received: by gwb20 with SMTP id 20so451091gwb.17 for ; Tue, 26 Jul 2011 07:43:40 -0700 (PDT) Received: by 10.68.46.102 with SMTP id u6mr8620753pbm.523.1311691420167; Tue, 26 Jul 2011 07:43:40 -0700 (PDT) Received: from coign.google.com ([67.218.105.144]) by mx.google.com with ESMTPS id d1sm626745pbj.72.2011.07.26.07.43.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jul 2011 07:43:39 -0700 (PDT) From: Ian Lance Taylor To: Agner Fog Cc: gcc-help@gcc.gnu.org Subject: Re: Is it OK that gcc optimizes away overflow check? References: <4E2B2B72.9050504@agner.org> <4E2E6CC6.3040106@agner.org> Date: Tue, 26 Jul 2011 14:44:00 -0000 In-Reply-To: <4E2E6CC6.3040106@agner.org> (Agner Fog's message of "Tue, 26 Jul 2011 09:29:10 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes 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 X-SW-Source: 2011-07/txt/msg00264.txt.bz2 Agner Fog 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: =C3=A2optimize=C3=A2 attribute > directive ignored. When I compile this test case with current gcc mainline #include 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 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