From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 1F98C3858C52 for ; Wed, 10 Apr 2024 10:17:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1F98C3858C52 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1F98C3858C52 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=89.208.246.23 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712744238; cv=none; b=JLlqH7+sIqFxdF/GbI1piCa6dAn03PF17dJLlh5FBp+30s63MmD0jzcJ6yhQbgOylT8uXn1ZQbdhQawD9rI6+LGRtPiywkkDqoR6IDVLAi9ns656AMlFlrJZcG6/SRoZgh0DdoM80wG7UdneGid16ONsqMP65C5R2L151Jonqzw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712744238; c=relaxed/simple; bh=UdyHuBi1klYaGcXcr1w0djNR4WPIRgE7Dv1jFpChMww=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=GFmPukt+FFOBJK02g3+xERMlHMrx4oijyXRGCWsv4Uk1EBfFa6mBRkj4/A5VsLiWA0asOsbq467fs5h+qlOiw097bLe49/zipwSee3bcqD0PaIJh2j7z9AjB3Baqfkzps6EB16O5lHQp8VvvNTXNWqJh7rSPJ46im/L5lvVRZvo= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1712744235; bh=UdyHuBi1klYaGcXcr1w0djNR4WPIRgE7Dv1jFpChMww=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=TWlZR32baTp7c+xoECmkqjz09+nJVTrB+ven6uOqAgMDVuAqGL0HkEG5q9Ygnw7N2 gcEzlJJ9fT13/cxg6JNVY0F80Cxg3xD2IRB6iykSAnZaWr3VWLj36SyFT4fuZkr8PM 8CTETO2k7NF3v9pI8xQWqTwDgLmVdbixUk2KFzYc= Received: from [127.0.0.1] (unknown [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id ADCB366C12; Wed, 10 Apr 2024 06:17:14 -0400 (EDT) Message-ID: <5f93b034b741790021d568995abe46ea8a164e6b.camel@xry111.site> Subject: Re: optimizer discards sign information From: Xi Ruoyao To: LIU Hao Cc: gcc-help@gcc.gnu.org Date: Wed, 10 Apr 2024 18:17:12 +0800 In-Reply-To: References: <016501da8b24$735d5170$5a17f450$@franke.ms> <5379650ad2582ae97c40ef1a78ded354033d2f71.camel@xry111.site> <0c105596-ecca-4936-84b0-b2f081b47bf2@126.com> <2e2c1430-edfa-42ed-8713-cff56a2de64d@126.com> <5f1da8b7829b4b1a445aac2216f50aba2fb5dac5.camel@xry111.site> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.0 MIME-Version: 1.0 X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_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: On Wed, 2024-04-10 at 18:07 +0800, LIU Hao wrote: > =E5=9C=A8 2024-04-10 17:52, Xi Ruoyao via Gcc-help =E5=86=99=E9=81=93: > > No, the OP is still thinking it's a wrong-code. >=20 > Would you read the Subject please? >=20 >=20 > =C2=A0=C2=A0=C2=A0=C2=A0 u32 x =3D a * b; > =C2=A0=C2=A0=C2=A0=C2=A0 u64 r =3D x; > =C2=A0=C2=A0=C2=A0=C2=A0 return r; >=20 > This is same as >=20 > =C2=A0=C2=A0=C2=A0=C2=A0 u32 x =3D (int) a * (int) b; > =C2=A0=C2=A0=C2=A0=C2=A0 u64 r =3D x; > =C2=A0=C2=A0=C2=A0=C2=A0 return r; >=20 > and >=20 > =C2=A0=C2=A0=C2=A0=C2=A0 return (u64)(u32) ((int) a * (int) b); >=20 >=20 > The code requests an `int` be zero-extended to a `u64` (if the result is = written to EAX then this is=20 > no-op), but GCC performs sign extension anyway. Do you still consider it = not a bug? It is a missed-optimization, but not wrong code. The code does not requests an *arbitrary* int to be zero-extended to a u64. It requests a value which can be proven as non-negative to be zero-extended. Thus doing a sign-extension may be sub-optimal (depending on the context and the target feature etc), but not wrong. u32 x =3D (int) a * (int) b; Here a and b are u16, so both (int) a and (int) b are non-negative. And since signed-overflow is UB, x is non-negative too. And for a non- negative int x, (u64)x is just same as (u64)(u32)x. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University