From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 4499F3858D20 for ; Wed, 10 Apr 2024 09:49:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4499F3858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=franke.ms Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=franke.ms ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4499F3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712742565; cv=none; b=ovS3Qp5SpGR6KLxNAiI4Ud2GBnjuof7HC5PKKrnuicq+jKqY/DzYa87uiRBOasy8nsYDmfmrDuiqnVokGbJXc599p/8UYSCQ+9hQbqzdnaKJ4vs29zSKbYpD/BHApRro36hz4UI31iOL82/yMjB2j3FVdaK1YElNHIqAFpUBOB4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712742565; c=relaxed/simple; bh=22qtQVmdzH7Bmk7Q20+WtvbtvvIBaFVeSyyd0j5HDqM=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=FOG/ma9rDYULVNrieM0F5cZBSqu7clhlmHPbIJDsKWOKtnmNT77LKpRDr8fsG5LAb9PZJf+J9aXDD1IbndvCS2zyEL0UMRwmwUROudZWUeBTjPk1RMJoXLvum8uKtsyFWgPRt012QlshLQhGIj46VnL1WV4Xf7vzcqZFDMglI2U= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from serveronline.org ([136.243.37.185] helo=franke.ms) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ruUa0-0002sH-O7 for gcc-help@gcc.gnu.org; Wed, 10 Apr 2024 05:49:22 -0400 Received: from HP (i59F6C2ED.versanet.de [89.246.194.237]) by serveronline.org (BEJY V1.6.12-SNAPSHOT (c) 2000-2021 by BebboSoft, Stefan "Bebbo" Franke, all rights reserved) with SMTP id 18ec76963fd06012b578a785b40 from stefan@franke.ms for gcc-help@gcc.gnu.org; Wed, 10 Apr 2024 10:49:16 +0100 From: To: References: <016501da8b24$735d5170$5a17f450$@franke.ms> <018301da8b28$e7a601e0$b6f205a0$@franke.ms> In-Reply-To: <018301da8b28$e7a601e0$b6f205a0$@franke.ms> Subject: AW: optimizer discards sign information Date: Wed, 10 Apr 2024 11:49:16 +0200 Message-ID: <018d01da8b2c$59e89e90$0db9dbb0$@franke.ms> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKuCbgyyRvVekTyfwew2Mt8FsUa6QH/MXceAlSEnO6vl6b74A== Content-Language: de Received-SPF: pass client-ip=136.243.37.185; envelope-from=stefan@franke.ms; helo=franke.ms X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9,SPF_HELO_PASS=-0.001,SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_FAIL,SPF_HELO_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > -----Urspr=C3=BCngliche Nachricht----- > Von: Gcc-help Im = Auftrag > von stefan@franke.ms > Gesendet: Mittwoch, 10. April 2024 11:25 > An: gcc-help@gcc.gnu.org > Betreff: AW: optimizer discards sign information >=20 > > -----Urspr=C3=BCngliche Nachricht----- > > Von: Alexander Monakov > > Gesendet: Mittwoch, 10. April 2024 11:17 > > An: stefan@franke.ms > > Cc: gcc-help@gcc.gnu.org > > Betreff: Re: optimizer discards sign information > > > > > > On Wed, 10 Apr 2024, stefan@franke.ms wrote: > > > > > Hi all, > > > > > > I just stumbled over an issue, which is present in almost all gcc = versions. > > > I worked around using inline assembly=E2=80=A6 Maybe gcc behaves = correct and > > > I am wrong? Here is the code: > > > > > > https://godbolt.org/z/cW8jcdh56 > > > > > > typedef unsigned long long int u64; > > > typedef unsigned int u32; > > > typedef unsigned short u16; > > > > > > u64 foo(u16 a, u16 b) { > > > u32 x =3D a * b; > > > u64 r =3D x; > > > return r; > > > } > > > > > > And on gcc 13.2 x86.64 you get > > > > > > foo: > > > movzx esi, si > > > movzx edi, di > > > imul edi, esi > > > movsx rax, edi > > > ret > > > > > > > > > There is a sign extension! The optimizer step discards the > > > information > > > > > > x_6 =3D (u32) _3; > > > > > > and uses _3 directly instead, which is signed. > > > > > > Am I wrong or is it gcc? > > > > GCC is not wrong. When your code computes x: > > > > u32 x =3D a * b; > > > > 'a' and 'b' are first promoted to int according to C language rules, > > and the multiplication happens in the signed int type, with UB on = overflow. > > The compiler deduces the range of signed int temporary holding the > > result of the multiplication is [0, 0x7fffffff], which allows to > > propagate it to the assignment of 'r' (which in the end produces a > > sign extension, as you observed, so the propagation did not turn out = to be > useful). > > > > u16 * u16 is a famous footgun for sure. I'd suggest 'x =3D 1u * a * = b' > > as a fix for the code. > > > > Alexander >=20 > Thank you for the fix =F0=9F=98=8A > I considered >=20 > u32 x =3D a * b; >=20 > as good enough, since from my understanding, x *is* unsigned. >=20 > Adding the multiplication with 1u resolves this. >=20 > regards >=20 > Stefan But I keep considering this as a bug. And clang behaves correctly! https://godbolt.org/z/az8WqboET typedef unsigned long long int u64; typedef unsigned int u32; typedef unsigned short u16; u64 foo(u16 *a, u16 *b) { u32 x =3D *a * *b; u64 r =3D x; return r >> 31; } gcc yields foo: xor eax, eax ret clang yields foo: # @foo movzx ecx, word ptr [rdi] movzx eax, word ptr [rsi] imul eax, ecx shr eax, 31 ret regards Stefan