From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stefan.kanthak@nexgo.de>
Received: from vsmx011.vodafonemail.xion.oxcs.net
 (vsmx011.vodafonemail.xion.oxcs.net [153.92.174.89])
 by sourceware.org (Postfix) with ESMTPS id 93DA93892002
 for <gcc-patches@gcc.gnu.org>; Wed, 11 Nov 2020 08:36:32 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 93DA93892002
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=nexgo.de
Authentication-Results: sourceware.org;
 spf=pass smtp.mailfrom=stefan.kanthak@nexgo.de
Received: from vsmx003.vodafonemail.xion.oxcs.net (unknown [192.168.75.197])
 by mta-5-out.mta.xion.oxcs.net (Postfix) with ESMTP id BDD3D59D4BE;
 Wed, 11 Nov 2020 08:36:30 +0000 (UTC)
Received: from H270 (unknown [91.56.252.193])
 by mta-7-out.mta.xion.oxcs.net (Postfix) with ESMTPA id 408C6539C2A;
 Wed, 11 Nov 2020 08:36:24 +0000 (UTC)
Message-ID: <7ACCC74B62494C2AB3DB97BA1983164B@H270>
From: "Stefan Kanthak" <stefan.kanthak@nexgo.de>
To: "Jakub Jelinek" <jakub@redhat.com>,
	"Jeff Law" <law@redhat.com>
Cc: <gcc-patches@gcc.gnu.org>
References: <116F1589A8244FB494091BCD4E6398AB@H270>
 <c5e5881c-116d-2ecc-81ea-e86475618529@redhat.com>
 <20201110235305.GE3788@tucnak>
In-Reply-To: <20201110235305.GE3788@tucnak>
Subject: Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions,
 plus fixed __bswapsi2 function
Date: Wed, 11 Nov 2020 09:33:00 +0100
Organization: Me, myself & IT
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18197
X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.24158
X-VADE-STATUS: LEGIT
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 RCVD_IN_DNSWL_LOW, 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 <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2020 08:36:34 -0000

Jakub Jelinek <jakub@redhat.com> wrote:

> On Tue, Nov 10, 2020 at 04:48:10PM -0700, Jeff Law via Gcc-patches wrote:
>> > @@ -486,10 +425,10 @@
>> >  SItype
>> >  __bswapsi2 (SItype u)
>> >  {
>> > -  return ((((u) & 0xff000000) >> 24)
>> > -   | (((u) & 0x00ff0000) >>  8)
>> > -   | (((u) & 0x0000ff00) <<  8)
>> > -   | (((u) & 0x000000ff) << 24));
>> > +  return ((((u) & 0xff000000u) >> 24)
>> > +   | (((u) & 0x00ff0000u) >>  8)
>> > +   | (((u) & 0x0000ff00u) <<  8)
>> > +   | (((u) & 0x000000ffu) << 24));
>>
>> What's the point of this change? I'm not sure how the signedness of the
>> constant really matters here.
>
> Note 0xff000000 is implicitly 0xff000000U because it doesn't fit into signed
> int, and that is the only one where the logical vs. arithmetic right shift
> really matters for correct behavior.

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!

JFTR: both -fsanitize=signed-integer-overflow and -fsanitize=undefined fail
      to catch this BUGBUGBUG, which surfaces on i386 and AMD64 with -O1 or
      -O0!
Stefan Kanthak

PS: even worse, -fsanitize=signed-integer-overflow fails to catch 1 << 31
    or 128 << 24!