[Bug tree-optimization/98097] New: Missing warning about strcmp (char[4], "BARZ")

[Bug tree-optimization/98097] New: Missing warning about strcmp (char[4], "BARZ")

[rguenth at gcc dot gnu.org]

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

            Bug ID: 98097
           Summary: Missing warning about strcmp (char[4], "BARZ")
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

#include <string.h>

struct info {
   char type[4];
   unsigned int status;
};

int foo (struct info *i)
{
  return strcmp (i->type, "ECKD") == 0;
}

Does not warn with -Wstring-compare, the variant with i passed by value does.

[Bug tree-optimization/98097] Missing warning about strcmp (char[4], "BARZ")

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Likely because &i->type is not a gimple invariant and thus in a separate stmt?

[Bug tree-optimization/98097] Missing warning about strcmp (char[4], "BARZ")

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |msebor at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2020-12-02
     Ever confirmed|0                           |1

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
The failure to diagnose this is due to the warning using the same conservative
assumption as for the strcmp and strlen optimization.  The optimization assumes
that strlen(i->type) is bounded by the size of the object i points to if it can
be determined, or by MAX_OBJECT_SIZE if not.  (You'll recall the long,
contentious  discussion about this.)  This assumption is overly conservative
for warnings but because -Wstring-compare was an optimization first and the
warning only an afterthought (after testing showed the optimization didn't
trigger enough to matter), I didn't remember to decouple the two.  Let me do
that.

[Bug tree-optimization/98097] Missing warning about strcmp (char[4], "BARZ")

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For optimizations indeed we shouldn't do any such assumptions, the fact that
the function is called with a particular pointer type doesn't necessarily mean
that is the dynamic type of the underlying object, and strcmp etc. functions
read or write the memory through char type which can alias anything.
But for warnings, we can indeed use the passed in type as a reasonable hint
what is ok and what is suspicious.

[Bug tree-optimization/98097] Missing warning about strcmp (char[4], "BARZ")

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch

--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563036.html