[Bug c++/95148] New: -Wtype-limits always-false warning triggered despite comparison being avoided

[Bug c++/95148] New: -Wtype-limits always-false warning triggered despite comparison being avoided

[eyalroz at technion dot ac.il]

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

            Bug ID: 95148
           Summary: -Wtype-limits always-false warning triggered despite
                    comparison being avoided
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eyalroz at technion dot ac.il
  Target Milestone: ---

Consider the following program:

  #include <type_traits>

  int main() {
          unsigned x { 5 };
          return (std::is_signed<decltype(x)>::value and (x < 0)) ? 1 : 0;
  }

when compiling it with GCC versions 11.0 20200511, 10.1, 9.2.1, 8.3.0, I get
the warning:

  a.cpp:5:52: warning: comparison of unsigned expression < 0 is always false
[-Wtype-limits]

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`.
This can be easily determined by the compiler - and probably is. No less
importantly, the author of such a line in a program clearly specified his/her
intent here with this check. 

clang doesn't seem to issue a warn inf does come to pass.

[Bug c++/95148] -Wtype-limits always-false warning triggered despite comparison being avoided

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=4210

--- Comment #1 from Eric Gallager <egallager at gcc dot gnu.org> ---
I think this counts as an example of bug 4210

[Bug c++/95148] -Wtype-limits always-false warning triggered despite comparison being avoided

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre <vincent-gcc at vinc17 dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vincent-gcc at vinc17 dot net

--- Comment #2 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
Simpler code, also for C:

int f (void)
{
  unsigned int x = 5;
  return 0 && x < 0 ? 1 : 0;
}

Alternatively:

int f (void)
{
  unsigned int x = 5;
  if (0)
    return x < 0 ? 1 : 0;
  return 0;
}

With -Wtype-limits, GCC 12.2.0 warns on both.

[Bug c++/95148] -Wtype-limits always-false warning triggered despite comparison being avoided

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Eyal Rozenberg from comment #0)
>   a.cpp:5:52: warning: comparison of unsigned expression < 0 is always false
> [-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. 

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<decltype(x)>)
    return x < 1;
  return false;

(This feature only makes sense in template code, but then so does testing
is_signed.) 

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 don't
know if that's currently possible in GCC.

[Bug c++/95148] -Wtype-limits always-false warning triggered despite comparison being avoided

[eyalroz1 at gmx dot com]

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

--- Comment #4 from Eyal Rozenberg <eyalroz1 at gmx dot com> ---
(In reply to Jonathan Wakely from comment #3)

> > 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.

But the semantics are known at compile time, and so are the argument values.

> > No less
> > importantly, the author of such a line in a program clearly specified
> > his/her intent here with this check. 
> 
> But `x && y` doesn't prevent y being instantiated, it only prevents it being
> evaluated at runtime.

You mean, it only prevents a comparison of an unsigned and signed values to
actually ever being carried out? Yeah :-)


> >   a.cpp:5:52: warning: comparison of unsigned expression < 0 is always false
> > [-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.

Well, that's a bug. If you're saying that the front-end produces the warning,
then delay it to a later stage, in which you can figure out whether the warning
is called for. 

clang doesn't produce this warning.

> 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
> don't know if that's currently possible in GCC.

Ok, I didn't say that the solution would be easy...