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 [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 7C2E639878B7 for ; Wed, 11 Nov 2020 09:55:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7C2E639878B7 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-574-ek3BXuQmNqG8ipZ7ojQUKw-1; Wed, 11 Nov 2020 04:55:15 -0500 X-MC-Unique: ek3BXuQmNqG8ipZ7ojQUKw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 316AC1087D82; Wed, 11 Nov 2020 09:55:14 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-113-127.ams2.redhat.com [10.36.113.127]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1FB3673669; Wed, 11 Nov 2020 09:55:12 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 0AB9tATU2857635 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 11 Nov 2020 10:55:10 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 0AB9t9e82857633; Wed, 11 Nov 2020 10:55:09 +0100 Date: Wed, 11 Nov 2020 10:55:09 +0100 From: Jakub Jelinek To: Stefan Kanthak Cc: Jeff Law , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function Message-ID: <20201111095509.GI3788@tucnak> Reply-To: Jakub Jelinek References: <116F1589A8244FB494091BCD4E6398AB@H270> <20201110235305.GE3788@tucnak> <7ACCC74B62494C2AB3DB97BA1983164B@H270> MIME-Version: 1.0 In-Reply-To: <7ACCC74B62494C2AB3DB97BA1983164B@H270> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, 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: Wed, 11 Nov 2020 09:55:18 -0000 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. Jakub