From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115503 invoked by alias); 6 Feb 2018 17:19:16 -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 115406 invoked by uid 89); 6 Feb 2018 17:19:15 -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=MUST, H*i:yiC7ax6XVvxGc, DOES, H*i:sk:rWGaBS_ 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 17:19:13 +0000 Received: from smtp03.uc3m.es (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A4D09DC078; Tue, 6 Feb 2018 18:19:10 +0100 (CET) Received: from smtp03.uc3m.es (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 96F8DDC06D; Tue, 6 Feb 2018 18:19:10 +0100 (CET) Received: from triangulo.it.uc3m.es (unknown [163.117.139.109]) by smtp03.uc3m.es (Postfix) with ESMTPS; Tue, 6 Feb 2018 18:19:10 +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 w16HJ9sq021515 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 6 Feb 2018 18:19:10 +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 w16HJ6nw020057; Tue, 6 Feb 2018 18:19:06 +0100 Received: (from ptb@localhost) by nbd.it.uc3m.es (8.13.1/8.13.1/Submit) id w16HJ6i9020055; Tue, 6 Feb 2018 18:19:06 +0100 From: "Peter T. Breuer" Message-Id: <201802061719.w16HJ6i9020055@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 17:19: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 04:45:05 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--19.864-5.0-31-10 X-TMASE-Version: IMSVA-9.1.0.1689-8.2.1013-23646.001 X-TMASE-Result: 10--19.864000-10.000000 X-TMASE-MatchedRID: xcONGPdDH5ov2k3M27J31vHkpkyUphL9rvgAq7dXvlqe9toQ6h6LE/eD X+4OWCzv3rS7kfUYal7xRPXdtpIOg4sU294fThvV7spMO3HwKCDLBdK2mpaYllpbYq2f4jz+ONd O69C+LDzJnXqrSPmdtmJJWch1uiKPQKbqzl//zc2LW79a3Y5EOrtW9LeKKGvbIeA9zgX9O/pLi7 50iAjLLwOXaXNpWK4y+H3jVLHvYoHi9mOUjCQGL2zBijri5+RVmX+W7bzPOQHwZxaFJX+r1fG39 9+Ui/tdUZoQAWo6HNmcEw5DXxd7SLl/NE0vQj9WonthQauQjAYLce5ZyDJAJg+8ritGY4+5m2M9 I54EAiXUn4uS1UDvWRRaEq8dgReKZPJiiebq1E+qEvbUNq/XjRkqnRJng/51TDLt4ErJxUF3VGh RLOTO1cs4E8fKsHRdH2XXM8w5v7pNfs8n85Te8v7E6GNqs6ce3QfwsVk0UbslCGssfkpInQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 X-SW-Source: 2018-02/txt/msg00030.txt.bz2 "Also sprach Jonathan Wakely:" > >> 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 :-(. > > You've already been told that 6.5.7 says "The integer promotions are > performed on each of the operands. " and says nothing about > conversions. If that were a valid mode of reasoning it would apply to the operands of arithmetic operators to which conversion IS applied. (Which are they?) Ergo, it is not. No flowers in this instance :-(. Is there somewhere where it DOES say that conversions should be applied to SOMETHING? > > 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. > > The specification of each operator tells you if it's applied. 6.5.7 > doesn't say they are, so they aren't. I don't have a "specification of each operator" to look at ... probably it doesn't junp out from google for me as easily as other stuff does. I wonder if I could I ask you to quote the ">>" specification for my lazy self? Perhaps also let me know what else conversion does and does not apply to? BTW, NOT saying something is applied in a specification should not mean that it is forbidden, as a general principle of specification languages. Is there somewhere in the C specification general blurb that says "no say, no do"? I admit my reason for supposing PROMOTION is not done was because I could find no rule that says to. But in that matter I am willing to believe it can or cannot be done in some (other) compiler implementation, whatever it should amount to in that case. Not doing is what happens with gcc. > > 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. > > Then you're not paying attention. You seem loathe to quote where it says that conversion MAY NOT or MUST NOT be applied to the arguments of >>. Unfortunately I can't work off word of mouth. Which of may or must not is it, since you know! > > 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. > > Is there somewhere in the standard where it SAYS ... Regards and thanks PTB