From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24374 invoked by alias); 6 Feb 2018 16:42:58 -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 23729 invoked by uid 89); 6 Feb 2018 16:42:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*i:sk:CAH6eHd, H*i:sk:G5g@mai, H*Ad:D*es, H*F:D*es X-HELO: smtp02.uc3m.es Received: from smtp02.uc3m.es (HELO smtp02.uc3m.es) (163.117.176.132) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Feb 2018 16:42:56 +0000 Received: from smtp02.uc3m.es (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B3BDE4055; Tue, 6 Feb 2018 17:42:52 +0100 (CET) Received: from smtp02.uc3m.es (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A5E5A404C; Tue, 6 Feb 2018 17:42:52 +0100 (CET) Received: from triangulo.it.uc3m.es (unknown [163.117.139.109]) by smtp02.uc3m.es (Postfix) with ESMTPS; Tue, 6 Feb 2018 17:42:52 +0100 (CET) Received: from nbd.it.uc3m.es (root@nbd.it.uc3m.es [163.117.139.192]) by triangulo.it.uc3m.es (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id w16GgqXC015801 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 6 Feb 2018 17:42:52 +0100 Received: from nbd.it.uc3m.es (localhost [127.0.0.1]) by nbd.it.uc3m.es (8.13.1/8.13.1/Debian-15) with ESMTP id w16GgmZS018030; Tue, 6 Feb 2018 17:42:48 +0100 Received: (from ptb@localhost) by nbd.it.uc3m.es (8.13.1/8.13.1/Submit) id w16GgmX7018028; Tue, 6 Feb 2018 17:42:48 +0100 From: "Peter T. Breuer" Message-Id: <201802061642.w16GgmX7018028@nbd.it.uc3m.es> Subject: Re: signed/unsigned integer conversion for right shift seems To: jwakely.gcc@gmail.com (Jonathan Wakely) Date: Tue, 06 Feb 2018 16:42:00 -0000 Cc: ptb@inv.it.uc3m.es, lh_mouse@126.com (Liu Hao), Peter.T.Breuer@gmail.com, gcc-help@gcc.gnu.org (gcc-help) In-Reply-To: from "Jonathan Wakely" at Feb 06, 2018 03:57:19 PM X-Anonymously-To: Reply-To: ptb@inv.it.uc3m.es X-WebTV-Stationery: Standard\; BGColor=black\; TextColor=black Reply-By: Sat, 1 Apr 2006 14:21:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-imss-scan-details: No--13.504-5.0-31-10 X-TMASE-Version: IMSVA-9.1.0.1689-8.2.1013-23646.001 X-TMASE-Result: 10--13.504400-10.000000 X-TMASE-MatchedRID: vEvJ7Rh1lGgv2k3M27J31ppWgCLYjjT9NNuh+5zmS69rEoFtNYg0C7Us JSfvHYrDh3AZ1hceMeKQvGteRbBT+LBAQLqGlKivU+OjsPhIWDgL8TGleseLPNqCxkzSpW/XNE7 kMskA+Nt6Vi5WLPMI2K603eM5LKoIR9t3jk6cD+5+7IhLVmN+uywJzaIVMjGt+0gZg08VXFqr/f b8n3rcRMGgqVPaULc7fkECcE2DrfI3IxyV+T0x7miYls8x2M90gdhI7ndNtODOxDyJFXIPjv7np 1jxGcScvbho6RQe4dTvn2kUJJww5JQRp/N2xyuybD4iYfbCo2PurwUTtj+IjaPMuQsqVNXhdHnb A2HfA0m8HbHOmebC88uMa3s/Qs+h5nXJvuEVye3mAId+2bAQwn0tCKdnhB58vqq8s2MNhPB9j2G wzTE3vSq2rl3dzGQ1mCku0AkNau8XUuxmJ1FwzsQYKXPmiXa6ANwCHAqSonu/Emt5SzN0gw== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 X-SW-Source: 2018-02/txt/msg00028.txt.bz2 "Also sprach Jonathan Wakely:" > > The usual arithmetic conversions are rules that provide a mechanism > > to yield a common type when both operands of a binary operator are > > ^^^^^^^^^^^^^^ > > balanced to a common type ... > > > > Ergo, one was unsigned, so they should both have been. > > No, because the operands of bitshift operators aren't balanced to a common type. Where does it say that? Your word isn't quite enough for me :-(. By the way, this is the conclusion I have come as being the most likely explanation by dint of certain weaselly words in the definition of when the CONVERSION rule should be applied (my caps): The usual arithmetic conversions are rules that provide a mechanism to yield a common type WHEN both operands of a binary operator are balanced to a common type or the second and third operands of the conditional operator ( ? : ) are balanced to a common type. Conversions involve two operands of different types, and one or both operands may be converted. MANY operators that accept arithmetic operands perform conversions using the usual arithmetic conversions. After integer promotions are performed on both operands, the following rules are applied to the promoted operands: It doesn't require the rules to be applied, it only talks about WHEN they are applied. It leaves it open as to to which operators that the conversion rules are to be appled to. What is the complement of the MANY, precisely? I am willing to accept that it includes ">>". Any more? "<<", I suppose, but the result would be insensitive to the change .. anything else? The first versus second/third arguments of ?:. And the arguments of the comma operator can be left to differ in type too, not that it makes any difference. > You asked for clarification and have got your answer, but seem > determined to stick to your original interpretation. No, I conclude whatever is logically required, and point out false aka mistaken logic where it is attempted. I don't mind what answer you or I get, so long as it is reasoned correctly, or at least convincingly. I haven't yet seen a constructive argument towards what I see as the probable out - that >> is just one of the 3 or 4 exceptions. Hmm ... would x/y show an effect like that? Yes. signed/unsigned is signed, with no conversion to a joint "unsigned" type taking place as per the conversion rule: If the operand that has unsigned integer type has rank greater than or equal to the rank of the type of the other operand, the operand with signed integer type is converted to the type of the operand with unsigned integer type. SO / and likely % (yes?) are likely other exceptions. That's >> << (?) / % (?) , ?: where no conversion after promotion occurs. The others are + - * and for them it doesn't matter as 2s complement gives the same result whatever. Is there somewhere in the standard where it SAYS this? Regards and thanks PTB