From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 129BB3858C27; Thu, 16 Dec 2021 01:27:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 129BB3858C27 From: "crazylht at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5 Date: Thu, 16 Dec 2021 01:27:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: blocker X-Bugzilla-Who: crazylht at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 01:27:17 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103194 --- Comment #23 from Hongtao.liu --- (In reply to Jakub Jelinek from comment #22) > (In reply to Hongtao.liu from comment #15) > > > Is the behavior well defined for n >=3D 64? I got > > >=20 > > > foo.c:11:19: warning: left shift count >=3D width of type > > > [-Wshift-count-overflow] > > > 11 | long mask =3D 1ll << 65; > > > | ^~ > > According to C99 > > The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bit= s are > > =EF=AC=81lled with zeros. If E1 has an unsigned type, the value of the = result is E1 > > =C3=97 2E2, reduced modulo one more than the maximum value representabl= e in the > > result type. If E1 has a signed type and nonnegative value, and E1 =C3= =97 2E2 is > > representable in the result type, then that is the resulting value; > > otherwise, the behavior is unde=EF=AC=81ned. > >=20 > > So yes, it's well defined, and the result is zero. >=20 > No, that isn't well defined in any C or C++ versions. > E.g. in C++: > https://eel.is/c++draft/expr.shift#1 > The behavior is undefined if the right operand is negative, or greater th= an > or equal to the width of the promoted left operand. > C99 6.5.7: > If the value of the right operand is negative or is > greater than or equal to the width of the promoted left operand, the > behavior is undefined. > What varies is whether shifting negative values left is well defined or n= ot, > or whether shifting bits into the sign bit of signed type is well defined= or > not. thanks for correction=EF=BC=8C I missed another paragraph=E3=80=82=20 ----cut from WG14-------- The integer promotions are performed on each of the operands. The type of t= he result is that of the promoted left operand. If the value of the right oper= and is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has an unsigned type, the value of the result is E= 1 =C3=97 2 E2, reduced modulo one more than the maximum value representable in the res= ult type. If E1 has a signed type and nonnegative value, and E1 =C3=97 2E2 is representable in the result type, then that is the resulting value; otherwi= se, the behavior is undefined. --------end--------- So, the result is undefined.=