From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88514 invoked by alias); 6 Feb 2018 16:17:41 -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 87107 invoked by uid 89); 6 Feb 2018 16:17:39 -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*Ad:D*es, Promotions, cmu, THAN X-HELO: smtp03.uc3m.es Received: from smtp03.uc3m.es (HELO smtp03.uc3m.es) (163.117.176.133) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Feb 2018 16:17:37 +0000 Received: from smtp03.uc3m.es (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C6BCEDC06A; Tue, 6 Feb 2018 17:17:33 +0100 (CET) Received: from smtp03.uc3m.es (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B94D3DC05F; Tue, 6 Feb 2018 17:17:33 +0100 (CET) Received: from triangulo.it.uc3m.es (unknown [163.117.139.109]) by smtp03.uc3m.es (Postfix) with ESMTPS; Tue, 6 Feb 2018 17:17:33 +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 w16GHW5M011913 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 6 Feb 2018 17:17:33 +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 w16GHTd5016632; Tue, 6 Feb 2018 17:17:29 +0100 Received: (from ptb@localhost) by nbd.it.uc3m.es (8.13.1/8.13.1/Submit) id w16GHTmL016630; Tue, 6 Feb 2018 17:17:29 +0100 From: "Peter T. Breuer" Message-Id: <201802061617.w16GHTmL016630@nbd.it.uc3m.es> Subject: Re: signed/unsigned integer conversion for right shift seems against To: tadeus.prastowo@unitn.it (Tadeus Prastowo) Date: Tue, 06 Feb 2018 16:17:00 -0000 Cc: ptb@inv.it.uc3m.es, Peter.T.Breuer@gmail.com, gcc-help@gcc.gnu.org (gcc-help) In-Reply-To: from "Tadeus Prastowo" at Feb 06, 2018 04:38:42 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--4.816-5.0-31-10 X-TMASE-Version: IMSVA-9.1.0.1689-8.2.1013-23646.001 X-TMASE-Result: 10--4.815600-10.000000 X-TMASE-MatchedRID: fE0JoqABJp0v2k3M27J31ppWgCLYjjT9TJDl9FKHbrlXgKFmMSOx5cWl hj9iHeVpbwLamxo/eoI9eFtS0rbQZ6NvJJBiq11akPoFsM336M4sleOknNBI0xpQU1f5QXKAjRw X3R5B4IjOCAcRMe05jQcqDLGJuOS7tXlQzVUq/kCzI1v7J4hEChHlzzcojFNOWltirZ/iPP7ybJ flErtwRbFE1DB2gVaRfP74yiWYCqBC9qEX7ASCsTS5nlobiSauoSsm92tWobF8xEUTnk6ZVGKD7 yWmgh0U9mO4udLA1/gSb55kiYr6J8PLtNmAuaGJ+JOTHACt+dfPAY6d6xdOFTnKpbGL4ChVUU5i dY48HIetalY5EY3e0ZC8a15FsFP4N5s8jM/6Mfx+7IhLVmN+u/qZGJlZc2fLbw988MsRNByjxYy RBa/qJX3mXSdV7KK4OubYLCVnBVFYF3qW3Je6++HHe3e2ABk/mEmePDaLMR1LhnTIYVGMxm0Suk /qmPZ4964W5hLtIFVKfY8R/LJlHmU/2otRNLQwdnOJNoWZBKJ4IV3+CYmz6Gx1EesWeuaEApvpD ZG9eMISntZZjLy1clUUv/tXDpBzo3cg1Vdbs6x+3BndfXUhXQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 X-SW-Source: 2018-02/txt/msg00026.txt.bz2 "Also sprach Tadeus Prastowo:" > > ...................................... The type of E1 is UNSIGNED INT > > by the type promotion/conversion rules I quoted. > > To quote the same document's Section 6.5.7 Paragraph 3: The integer > promotions are performed on each of the operands. The type of the > result is that of the promoted left operand. End quote. Yes, but no promotions are performed (I ceased reading the sentence at that point - hit me if I do wrong). I quote Integer Promotions Integer types smaller than int are promoted when an operation is ^^^^^^^^^^^^^^^^ performed on them. The types are not "smaller than int" here. (signed int and unsigned int respectively in x >> y). No promotions. I'll read on .. hmm. I don't actually care what the result type is (signed or unsigned - definitely int) is in this instance, as I don't use it except to print its bits. So I don't see the final sentence as relevant. That promotions (of which I contend there are none; penultimate sentence) are performed on each and all of the operands does not disturb me. None seem to have been performed, going by the result, so I do not see that sentence as relevant either. > And to quote Section 6.3.1.1 Paragraph 2: [...] If an int can > represent all values of the original type, the value is converted to > an int; otherwise, it is converted to an unsigned int. These are > called the integer promotions. All other types are unchanged by the > integer promotions. End quote. That is a quote for a promotion, of which none are performed. Let me fill out the quote (my caps) Integer types SMALLER THAN INT are promoted when an operation is performed on them. If all values of the original type can be represented as an int, the value of the smaller type is converted to an int; otherwise, it is converted to an unsigned int. Integer promotions are applied as part of the usual arithmetic conversions to certain argument expressions; operands of the unary +, -, and ~ operators; and OPERANDS OF THE SHIFT OPERATORS. Not smaller than int, so no promotions. (I'm quoting something at CMU, rather than wherever you are quoting from, https://wiki.sei.cmu.edu/confluence/display/c/INT02-C.+Understand+integer+conversion+rules simply because I have to quote something and that's what google is showing me) We should be looking at the rules for conversions, not promotions. > So, E1 has type signed int, hasn't it? No promotion is applied. I get what you saying, however, which is that zero promotions is a promotion (!), so we should end up with int from this nonexistent promotion of the left argument. I agree as far as that goes (see end of para), we should, but not by virtue of a promotion, but by the absence of a promotion. Everything is hunky dory as we are supposed to promote to ints (or unsigned ints) for arithmetic and we have that already. I contend we are then supposed additionally to CONVERT, not promote, by the "usual arithmetic conversion" rules. These rules include integer promotions, integer conversion rank, and the USUAL ARITHMETIC CONVERSIONS. Can you look at that? 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: The best explanation I have seen so far is that there is no WHEN here, because the MANY does not include >>. I have not been able to repy to what has seemed to me to be the only valid excuse - because of the deluge. Apologies to whoever it is. (I think I noticed the reasoning was a bit wonky there too, but maybe I was intoxicated when reading it). Regards PTB