From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D0A94384AB65; Thu, 16 May 2024 09:08:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D0A94384AB65 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1715850512; bh=UghLbEkia2Mck8cntdugl7i5SXI8iCbBrYGG4nnT6cU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=deEo8X/LMTVfGNRyiHnOSiv5fgsftRxHp5HFG/qFFV1mK6jQCNfgyMaZ92eFh+7Mh w0uZc88m2l/baOgZz7H/6u5tvEYBNtjfTtJWtuXXB3LfRdcTh/kAiIb7tg5ipPKgGt oy8jh8t/OqNZQ/bi6H/rUl+Nv8K3SLVih/xNUvKs= From: "slyfox at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/115115] [12/13/14/15 Regression] highway-1.0.7 wrong _mm_cvttps_epi32() constant fold Date: Thu, 16 May 2024 09:08:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: slyfox at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D115115 --- Comment #5 from Sergei Trofimovich --- (In reply to Andrew Pinski from comment #2) > So from a point of view of float to int conversion, both are valid for out > of range values. Looking at CVTTPS2DQ instruction from https://www.intel.com/content/www/us/en/developer/articles/technical/intel-= sdm.html "Intel=C2=AE 64 and IA-32 Architectures Software Developer=E2=80=99s Manual= Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4": """ Description ... When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception= is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned. """ It feels like 2^63 is an exact value and no truncation should happen. Thus 0x80000000 seems to be the correct value. Why 0x7fffffff would be a reasona= ble outcome as well? Is it because `_mm_cvttps_epi32()` semantics are not a 1-t= o-1 to CVTTPS2DQ instruction? Trying to understand the detail as I'm not yet sure if I should file a `highway` bug to be compatible with gcc's expectations. The exact test is at https://github.com/google/highway/blob/b7cff55896e36e6080909d35ef6fb3d0986b= 4cfa/hwy/tests/convert_test.cc#L1202=