From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20851 invoked by alias); 27 Mar 2009 12:49:54 -0000 Received: (qmail 20843 invoked by uid 22791); 27 Mar 2009 12:49:53 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-bw0-f161.google.com (HELO mail-bw0-f161.google.com) (209.85.218.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 27 Mar 2009 12:49:45 +0000 Received: by bwz5 with SMTP id 5so969306bwz.8 for ; Fri, 27 Mar 2009 05:49:42 -0700 (PDT) Received: by 10.103.229.12 with SMTP id g12mr415382mur.87.1238158182437; Fri, 27 Mar 2009 05:49:42 -0700 (PDT) Received: from scientist-2.local ([195.176.178.209]) by mx.google.com with ESMTPS id j10sm3114456muh.31.2009.03.27.05.49.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Mar 2009 05:49:41 -0700 (PDT) Message-ID: <49CCCB63.8050109@gnu.org> Date: Fri, 27 Mar 2009 18:07:00 -0000 From: Paolo Bonzini User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: eus@member.fsf.org CC: gcc@gcc.gnu.org Subject: Re: New no-undefined-overflow branch References: <49B1334F.1030805@gnu.org> <1238154719.6830.27.camel@eus-gnu-linux-laptop> In-Reply-To: <1238154719.6830.27.camel@eus-gnu-linux-laptop> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-03/txt/msg00815.txt.bz2 Eus wrote: > Hi Ho! > > On Fri, 2009-03-06 at 15:29 +0100, Paolo Bonzini wrote: >>> So while trapping variants can certainly be introduced it looks like >>> this task may be more difficult. >> I don't think you need to introduce trapping tree codes. You can >> introduce them directly in the front-end as >> >> s = x +nv y >> (((s ^ x) & (s ^ y)) < 0) ? trap () : s > > Could you please kindly explain a bit about it? > > Suppose s, x, and y are 8-bit signed integer. > If x and y are -128, s = (-128) + (-128), which will overflow. > Now if suppose s is 0, ((0 ^ -128) & (0 ^ -128)) == -128, which is less > than zero and will trap. This is correct. > But, if s is -128, ((-128 ^ -128) & (-128 ^ -128)) is zero and will not > trap. This is incorrect, isn't this? Don't look at it as an arithmetic test, "< 0" is just a shortcut for "the most significant bit of the first operand is 1". So the formula's outcome only depends on the ANDs and XORs of the sign bits; it means, "trap if the result's sign is different from both addends' signs" or equivalently "check that the result's sign matches at least one addend's sign". You can also say "((s ^ x) & ~(x ^ y)) < 0", or equivalently "((s ^ y) & ~(x ^ y)) < 0". These mean "trap if the two addends have the same sign and the sum has a different sign". It is easy to prove that they are equivalent: s x y s^x s^y ~(x^y) equal? 0 0 0 0 0 1 yes (0) 0 0 1 0 1 0 yes (0) 0 1 0 1 0 0 yes (0) 0 1 1 1 1 1 yes (1) 1 0 0 1 1 1 yes (1) 1 0 1 1 0 0 yes (0) 1 1 0 0 1 0 yes (0) 1 1 1 0 0 1 yes (0) Paolo