From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64605 invoked by alias); 6 Feb 2018 23:49:52 -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 64594 invoked by uid 89); 6 Feb 2018 23:49:52 -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,KAM_SHORT,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=relating, Semantics, borrow, prohibit 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 23:49:49 +0000 Received: from smtp03.uc3m.es (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7472BDC07A; Wed, 7 Feb 2018 00:49:46 +0100 (CET) Received: from smtp03.uc3m.es (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5CE27DC078; Wed, 7 Feb 2018 00:49:46 +0100 (CET) Received: from triangulo.it.uc3m.es (unknown [163.117.139.109]) by smtp03.uc3m.es (Postfix) with ESMTPS; Wed, 7 Feb 2018 00:49:46 +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 w16Nnjp9025204 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 7 Feb 2018 00:49:46 +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 w16NngP7008889; Wed, 7 Feb 2018 00:49:42 +0100 Received: (from ptb@localhost) by nbd.it.uc3m.es (8.13.1/8.13.1/Submit) id w16NngB3008887; Wed, 7 Feb 2018 00:49:42 +0100 From: "Peter T. Breuer" Message-Id: <201802062349.w16NngB3008887@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 23:49:00 -0000 Cc: ptb@inv.it.uc3m.es (Peter Breuer), lh_mouse@126.com (Liu Hao), Peter.T.Breuer@gmail.com (Peter Breuer), gcc-help@gcc.gnu.org (gcc-help) In-Reply-To: from "Jonathan Wakely" at Feb 06, 2018 08:11:49 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--11.887-5.0-31-10 X-TMASE-Version: IMSVA-9.1.0.1689-8.2.1013-23646.003 X-TMASE-Result: 10--11.886800-10.000000 X-TMASE-MatchedRID: gTucSmrmRMMv2k3M27J31vHkpkyUphL9im7lNffkTa40a9W1gvZ4t242 Q6gP826QKNLrUo1TED36VzJBfHIuerDMW7LJrZawwEbFmwMi1zM6QNs2WCY79Rc+nzs86r3GrQX C1SFTGNLr8n6aoHCbnFeMrG9FIBQhFohKFQUjhh1NI82n17+7Uz8V4lh/3DF1SCDBuEaODKZ9jy 7nF28ku6N7Uinr/dLyZkDFuwiGBp65rzEqaXlmzY1nuRzhSr7jCPwIAmI5pP4R34ro7k23nTxAB 3/WESfJA2yA9dLr1uBmTh0LUkgT61fnsPC4h9MjBtTZHAJnUeDA2cNJy/qKUtqCxkzSpW/XAitv bsFmgfLh86Pz6wHGfzb4UExMs2L3E1ZZbRf/HMzuykw7cfAoIJOBXaF4TRYNFFn/3AEyEayu0fu 9dAyeQ8htaRMr0pDKMXTmye4R4QR//2guIJ+U2G/+RwWenb0YTJDl9FKHbrkNht78/JfyBNR20c zsQpZHdzlaPxY4Wvzaqtou7svYigmGbpOMTi81AFhQPeH80f8pWss5kPUFdBr/NZtDPe8OG2Mkg eeC0TE3qVcNSJ+oBH/Me0m0hCeyhX5iFpQv8SjkNIw8RlACQ8TfSi2Auq7RGL1FL/bt1Y1yGSnn q2SjBxWNRqUlzlY6nE9317dblWor9jdu7nFqnJ4CIKY/Hg3AtOt1ofVlaoKm8jxRk5/juFFFNPv ceECvtVC7UY1n6yI7AFczfjr/7GNcIBY3dExI7c8/qlbEpbZjXGzQg7LbZQR84w2+CLB3r9rgza tEf78= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 X-SW-Source: 2018-02/txt/msg00046.txt.bz2 "Also sprach Jonathan Wakely:" > >> Are you trolling or just stubborn and unable to accept the help you asked for? > > > > I would be grateful if you desisted from ad hominen attacks. > > Stop acting like an idiot then. See above. I and doubtless the world would appreciate it if you refrained. > > WHAT, specifically, do you see in 6.5.7 that allows the conversion > > specified by the general rule of conversions > > > > If one operand has an unsigned type T whose conversion rank is at least > > as high as that of the other operand's type, then the other operand is > > converted to type T. > > > > NOT to be applied? > > Because it doesn't say they are applied. As I pointed out in An interesting new theory, if late to the party. You now say that the phrase "the usual arithmetic conversions" (6.3.1.8) must be present in the subsection relating to the operator? Ingenious, and I'll look at that as a possibility. Let's test. According to the index, the phrase occurs in usual arithmetic conversions, 6.3.1.8 [defn], 6.5.5, 6.5.6, 6.5.8, 6.5.9, 6.5.10, 6.5.11, 6.5.12, 6.5.15 6.5.5 = multiplicative ops (* / %) 6.5.6 = additive ops (+ -) 6.5.8 = order relations (> < <= >=) 6.5.9 = equals relns 6.5.10= bitwise & 6.5.11= bitwise ^ 6.5.12= bitwise | 6.5.15= ternery op ?: That looks plausible. 6.5.7 (>> and <<) is about all that's missing. The rubric usually goes Semantics 3 The usual arithmetic conversions are performed on the operands. and it is not present in 6.5.7, which instead has Semantics 3 The integer promotions are performed on each of the operands. We (I!) have throughout the thread noted that there are no promotions to be done here as both args are already int. The possible argument put forward by someone that promotions are "a part" of conversions and no promotions implies no conversions, I did not find convincing (it's possible to be a not-there part of a thing with extent, like windows in a room; a room does not _have_ to have windows). So this looks the strongest argument so far. Well done. > https://gcc.gnu.org/ml/gcc-help/2018-02/msg00031.html the other > operators *do* say the conversions are applied. Indeed. Strong argument, comparing the other op specs in deatil. > > The arguments of the following arithmetic operators undergo implicit > > conversions for the purpose of obtaining the common real type, which > > is the type in which the calculation is performed: > > binary arithmetic *, /, %, +, - > > relational operators <, >, <=, >=, ==, != > > binary bitwise arithmetic &, ^, |, > > the conditional operator ?: > > > > That's all. No ">>" operator there, so no maybe. Your claim is false > > there. > > Exactly, the shift operators are not listed there, because the > conversions are not done for the shift operators. That doesn't work as logic - it's circumstantial and unsafe as a mode of reasoning. The += is also an (impure) arithmetic operator and it should follow the same conversion rule as +, which is in your/that list. A compound assignment of the form E1 op = E2 differs from the simple assignment expression E1 = E1 [+|-] (E2) only in that the lvalue E1 is evaluated only once. According to that it does borrow the semantics of + which explicitly has the "usual arithmetic conversions" phrase, yet the phrase doesn't appear in the text for += and the operator is not listed in the set you gave. So according to your reasoning it should NOT have the "usual arithmetic conversions", yet it does. [There looks a semantic morass here, since the two imaginary appearances of the lhs might get two different types through the rules. It's not as simple as foo=foo op bar, and what it boils down to exactly depends on the lhs and the rhs, especially in case of explicit side-effects in those.] > >> http://en.cppreference.com/w/c/language/operator_arithmetic#Shift_operators > > > > That's a different place ... it seems to say what we have already > > quoted in the standard. > > > > First, integer promotions are performed, individually, on each operand > > (Note: this is unlike other binary arithmetic operators, which all > > perform usual arithmetic conversions). The type of the result is the > > type of lhs after promotion. > > > > No integer promotions can be performed, since the args are already ints. > > Read the parenthesis! It explicitly says that for these operators, > unlike most others, arithmetic conversions are not performed! It doesn't say so explicitly (but you have - explicitly would be saying, as you did above, "the usual arithmetic conversions are not performed"). You are saying it is not explicit but it is implicit? Could be ... could be not. Hard to say. So it is not. Implicit means logically deducible, "implied though not directly expressed", as the dictionary has it. I don't see it as a _necessary_ consequence, just a possible one. To explain, there's that finesse over whether promotions are supposed to be a part of conversion (see somebody else in this thread, maybe even you for all I know right now!) or not to consider, plus whether they're lax or not in differentiating promotions from conversions. One could plausibly read this text as saying that promotions are performed in this case whereas they are omitted in other cases, but in all or some or many cases, including this, one goes on to perform the rest of the conversions apart from the promotions. In my opinion, however, this is corroborating evidence in favor. But its's still just circumstantial stuff. One has to watch out for circumstantial evidence and not jump to conclusions (engineers make that logical mistake, as a general rule, for lack of abstract thinking pathways). > > There is no "Second". > > > > If they meant to say > > > > "Second: NO sign conversions MAY be performed, so what you get after > > (possibly vacuuous) int promotion you are stuck with, " > > > > then they forgot to say it. > > You are an idiot. Desist from insults and attacks. I have written an appropriate sentence that would explicitly prohibit arithmetic conversion for >> in any conforming compiler implementation. Why haven't they? Check out the "Dunning-Krueger effect" on Wikipedia. To me, the spec looks pretty much collated from older bits of spec, updated imperfectly. Shrug. What isn't? I'll see if I can talk to somebody on the WG. Regards PTB