From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85172 invoked by alias); 6 Feb 2018 16:45:34 -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 85005 invoked by uid 89); 6 Feb 2018 16:45:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:G5g@mai, paying X-HELO: mail-it0-f50.google.com Received: from mail-it0-f50.google.com (HELO mail-it0-f50.google.com) (209.85.214.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Feb 2018 16:45:18 +0000 Received: by mail-it0-f50.google.com with SMTP id x128so3284880ite.0 for ; Tue, 06 Feb 2018 08:45:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6WorxtH2DDRy8Oys2a0w9hop6uWaBibTJMa8bDYmBXk=; b=PqX75UxXD9PSSHmmbJJh7WHDbS3Znah4Cht72U0J/Ma22orVW2oqAxJtSWKTpeACeK MFD+4yic21DJ+8+8Uwq1e619ue+G8bsjutbwKmqtGk+DcMVnarkI7BMeUDzfR3VChCm3 KW6GTiQrwrgnwe2KKmCMonhJx+TcrNO5zRK5Ko/ZcxbotqlEzW1MGmuf1oKsJEkK5DSQ E9HetpgrVwcKjKQgJoMSQQEJ59Eqx7z2IEZQ8bZVHnPPQHGqLXYCrpuTzOCSBVW/Z1rd k4Rx3z5uodGfVP76aEsuFZb/HRZcZBf+Vsi2zs+Hd8Bv6BQP7JqvHBZiD7RIqWDFItmU X1lw== X-Gm-Message-State: APf1xPDZHryiDP45fLiq6o8lpFbXyYaq40R0hogKbPVDxHvJS0EMkkL9 O1FBn7Cy6A1pa0LYNx/3JarNK16jAN5arF9eX4E= X-Google-Smtp-Source: AH8x224wCUfx4SBCZlR2X0OXQIc8ePZvFA6p3GD692R2lHn+28ghPdhZJ8UPCnFRTgI1WD1iTKv5/BqR9NiFlbXRYGo= X-Received: by 10.36.253.6 with SMTP id m6mr3930376ith.132.1517935506147; Tue, 06 Feb 2018 08:45:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.50.198 with HTTP; Tue, 6 Feb 2018 08:45:05 -0800 (PST) In-Reply-To: <201802061642.w16GgmX7018028@nbd.it.uc3m.es> References: <201802061642.w16GgmX7018028@nbd.it.uc3m.es> From: Jonathan Wakely Date: Tue, 06 Feb 2018 16:45:00 -0000 Message-ID: Subject: Re: signed/unsigned integer conversion for right shift seems To: ptb@inv.it.uc3m.es Cc: Liu Hao , Peter.T.Breuer@gmail.com, gcc-help Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00029.txt.bz2 On 6 February 2018 at 16:42, Peter T. Breuer wrote: > "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 :-(. 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. > 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. The specification of each operator tells you if it's applied. 6.5.7 doesn't say they are, so they aren't. > 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. Then you're not paying attention. > 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 >