From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id EB2273858CD1; Fri,  8 Dec 2023 19:33:24 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EB2273858CD1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1702064004;
	bh=SBBjFOGxJNIaTOW4iiW/cdPA3JDnwM2z0Ju3HT1KBWs=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=NgXTlsUQJjMzsM5LM4i7kp/Lu6HtZY8psXH3inyXrkzy6a+9EhKSJLwTV8hjuxY+b
	 nqvDMEYOINQZeQeHNaFwlq3EJuIauQ+EwQ1S4Gm55HeLIgfB82LR48LK6XCwL3t22a
	 VaJYt0A0gKOU0aJG3yJdAYmUeHSGnvXhGh+YIrv4=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/112758] [13/14 Regression] Inconsistent
 Bitwise AND Operation Result between int and long long int
Date: Fri, 08 Dec 2023 19:33:24 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: needs-bisection, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-112758-4-qpfU67MY3C@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-112758-4@http.gcc.gnu.org/bugzilla/>
References: <bug-112758-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112758

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Oh, and the reason why given the above=20
(and:DI (subreg:DI (mem/c:SI (lo_sum:DI (reg/f:DI 144)
                (symbol_ref:DI ("globalVar") [flags 0x86] <var_decl
0x7fffea1f9b40 globalVar>)) [1 globalVar+0 S4 A32]) 0)
    (const_int -280375465082881 [0xffff00ffffffffff]))
is optimized into the zero extension is the following in combine.cc:
      /* If the one operand is a paradoxical subreg of a register or memory=
 and
         the constant (limited to the smaller mode) has only zero bits where
         the sub expression has known zero bits, this can be expressed as
         a zero_extend.  */
      else if (GET_CODE (XEXP (x, 0)) =3D=3D SUBREG)
        {
          rtx sub;

          sub =3D XEXP (XEXP (x, 0), 0);
          machine_mode sub_mode =3D GET_MODE (sub);
          int sub_width;
          if ((REG_P (sub) || MEM_P (sub))
              && GET_MODE_PRECISION (sub_mode).is_constant (&sub_width)
              && sub_width < mode_width)
            {
              unsigned HOST_WIDE_INT mode_mask =3D GET_MODE_MASK (sub_mode);
              unsigned HOST_WIDE_INT mask;

              /* original AND constant with all the known zero bits set */
              mask =3D UINTVAL (XEXP (x, 1)) | (~nonzero_bits (sub, sub_mod=
e));
              if ((mask & mode_mask) =3D=3D mode_mask)
                {
                  new_rtx =3D make_compound_operation (sub, next_code);
                  new_rtx =3D make_extraction (mode, new_rtx, 0, 0, sub_wid=
th,
                                             true, false, in_code =3D=3D CO=
MPARE);
                }
            }
        }
clearly, if the sign_bit_copies stuff is right for wordmode paradoxical SUB=
REGs
of smaller MEMs with load_extend_op (MEM_mode) =3D=3D SIGN_EXTEND, then this
optimization
needs to punt if those conditions are met and sub is a MEM.

Will defer this to people actually using WORD_REGISTER_OPERATIONS arches,
fortunately
none of the ones I'm involved with on a daily basis is.=