From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 103963857C64; Wed, 26 Oct 2022 09:49:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 103963857C64 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1666777754; bh=zDLHzHBvvYXlzyjbrSi1EC5UG1Esujcqqhur2rOjsD4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=wgFmhuIdd00zQ7m7RhkbS5tDOrZHpd/xr5evgqb6nZiG9JVF8PTCL/dfAmoHvyg1v SH0WH4T90xBd6mbh1N1tndymkhaB4rcru32CJvjHelhiZzbD/VWTIP6pMsnhI6UAEu VkAr6+tqj/+JjMji2MnkTBiU6ugMVzNxlXXhlkhY= From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/95148] -Wtype-limits always-false warning triggered despite comparison being avoided Date: Wed, 26 Oct 2022 09:49:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 10.1.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: redi 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: --- 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=3D95148 --- Comment #3 from Jonathan Wakely --- (In reply to Eyal Rozenberg from comment #0) > a.cpp:5:52: warning: comparison of unsigned expression < 0 is always fa= lse > [-Wtype-limits] Both branches of the condition must be instantiated by the compiler, and so this warning (which happens in the front-end, not after optimizing the AST) gets triggered. > I should not be getting this warning, because when x is unsigned, the > comparison is never performed, due to the short-circuit semantics of `and= `. Those semantics only apply at runtime. > This can be easily determined by the compiler - and probably is. Not in the compiler front end. > No less > importantly, the author of such a line in a program clearly specified > his/her intent here with this check.=20 But `x && y` doesn't prevent y being instantiated, it only prevents it being evaluated at runtime. This is a compile-time warning based on the types involved in the expression, and the expression is being compiled. This is analogous to false && func(x) which requires a definition of func(x) in the program even if it will never get called at runtime. If you want the comparison to be completely elided based on the type, then = the language provides a solution: if constexpr (is_signed_v) return x < 1; return false; (This feature only makes sense in template code, but then so does testing is_signed.)=20 I think to avoid this warning the front end would have to disable this particular warning for branches that depend on a compile-time constant. I d= on't know if that's currently possible in GCC.=