From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DF4953857C65; Sun, 15 Nov 2020 04:16:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DF4953857C65 From: "sven.koehler at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/97833] New: -Wconversion behaves erratic Date: Sun, 15 Nov 2020 04:16:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 10.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: sven.koehler at gmail dot com 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: 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: Sun, 15 Nov 2020 04:16:55 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97833 Bug ID: 97833 Summary: -Wconversion behaves erratic Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sven.koehler at gmail dot com Target Milestone: --- Created attachment 49559 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D49559&action=3Dedit non-working example Find attached an example for which -Wconversion behaves uncomprehensible. Why does it yields warning for test2 but not for test1 and test3? This happens with gcc for 32bit arm and gcc for x86_64. In all 3 functions, we have 2 shift operations. The operand is uint16_t, wh= ich is promoted to int. The result of the shift operations is cast to uint16_t.= So the operands of the bit-wise or are again uint16_t. So both operands of the bitwise or are promoted to int. So basically, in all 3 cases the code is returning an int. However, -W conversion warns only in 1 case. Also, why does it matter whether x is shifted by 0 or 1 ? Why does a shift = by 0 result in an error, and a shift by 1 does not? Why does it matter whether x and y are originally uint8_t being cast to uint16_t (test2) or a uint16_t (test3) originally? In both cases, the resul= t of the shifts is cast to uint16_t. Is gcc trying to keep track of the range of the individual expressions? Is = gcc somehow failing when the a shift by 0 occurs? I believe that a shift by zer= o is defined behavior.=