From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id E51593857021 for ; Mon, 23 Nov 2020 23:02:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E51593857021 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-323-2njhQPhuPtyhR7tv6PB0rQ-1; Mon, 23 Nov 2020 18:02:00 -0500 X-MC-Unique: 2njhQPhuPtyhR7tv6PB0rQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1E1551005E4B; Mon, 23 Nov 2020 23:01:58 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-152.phx2.redhat.com [10.3.113.152]) by smtp.corp.redhat.com (Postfix) with ESMTP id C6E425D9CA; Mon, 23 Nov 2020 23:01:53 +0000 (UTC) Subject: Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function To: Jakub Jelinek , Stefan Kanthak Cc: gcc-patches@gcc.gnu.org References: <116F1589A8244FB494091BCD4E6398AB@H270> <20201110235305.GE3788@tucnak> <7ACCC74B62494C2AB3DB97BA1983164B@H270> <20201111095509.GI3788@tucnak> From: Jeff Law Message-ID: Date: Mon, 23 Nov 2020 16:01:53 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <20201111095509.GI3788@tucnak> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 23:02:08 -0000 On 11/11/20 2:55 AM, Jakub Jelinek wrote: > On Wed, Nov 11, 2020 at 09:33:00AM +0100, Stefan Kanthak wrote: >> Ouch: that's but not the point here; what matters is the undefined behaviour of >> ((u) & 0x000000ff) << 24 >> >> 0x000000ff is a signed int, so (u) & 0x000000ff is signed too -- and producing >> a negative value (or overflow) from the left-shift of a signed int, i.e. >> shifting into (or beyond) the sign bit, is undefined behaviour! > Only in some language dialects. > It is caught by -fsanitize=shift. > In C++20, if the shift count is within bounds, all signed as well as > unsigned left shifts well defined. > In C99/C11 there is one extra rule: > For signed x << y, in C99/C11, the following: > (unsigned) x >> (uprecm1 - y) > if non-zero, is undefined. > and for C++11 to C++17 another one: > /* For signed x << y, in C++11 and later, the following: > x < 0 || ((unsigned) x >> (uprecm1 - y)) > 1 > is undefined. */ > So indeed, 0x80 << 24 is UB in C99/C11 and C++98, unclear in C89 and > well defined in C++11 and later. I don't know if C2X is considering > mandating two's complement and making it well defined like C++20 did. > > Guess we should fix that, though because different languages have different > rules, GCC itself except for sanitization doesn't consider it UB and only > treats shifts by negative value or shifts by bitsize or more UB. Even if it's well defined by C++20, I don't think we can rely on those semantics within libgcc2.  At best we might be able to claim C99 and we might even be stuck at C89, regardless of how GCC treats a shift into the sign bit. I'll do a bit of testing here, but I'm inclined to explicitly treat all those constants as unsigned for the sake of consistency.  Thanks Stefan for pointing out what I missed (shift into the sign bit). jeff