[Bug tree-optimization/97628] New: format truncation false positive for O1 and mtune=nocona

[Bug tree-optimization/97628] New: format truncation false positive for O1 and mtune=nocona

[walter.gcc at wjd dot nu]

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

            Bug ID: 97628
           Summary: format truncation false positive for O1 and
                    mtune=nocona
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: walter.gcc at wjd dot nu
  Target Milestone: ---

Created attachment 49468
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49468&action=edit
trimmed down problem from Asterisk say.c

Per the discussion here:
https://gerrit.asterisk.org/c/asterisk/+/14501

I believe there is a bug in gcc 9 where it falsely reports:

  warning: ‘%d’ directive output may be truncated writing
    between 1 and 11 bytes into a region of size 10
    [-Wformat-truncation=]

See the attached example, it only triggers when:

- optimization is 1 or higher
- arch tuning is set to nocona

Example:

$ gcc -O1 -mtune=nocona -S -Wall say2.c
say2.c: In function ‘ast_say_number_full_zh’:
say2.c:37:32: warning: ‘%d’ directive output may be truncated writing between 1
and 11 bytes into a region of size 10 [-Wformat-truncation=]
   37 |             snprintf(buf, 10, "%d", num);
      |                                ^~
say2.c:37:31: note: directive argument in the range [-2147483648, 9]
...

But when omitting either -O1 or -mtune=nocona we do not get this warning.

And if you read the code, you would see that at line 37, num cannot be negative
(because it would've hit a different if-branch).

gcc version is the Ubuntu/Focal one:

    $ gcc --version
    gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0


Cheers,
Walter Doekes
OSSO B.V.

[Bug tree-optimization/97628] format truncation false positive for O1 and mtune=nocona

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
             Blocks|                            |85741
      Known to fail|                            |10.2.0, 11.0, 9.3.0
   Last reconfirmed|                            |2020-10-29

--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
Confirmed with GCC 9 through 11.  The -Wformat-truncation and -Wformat-overflow
warnings rely on the range propagation engine in GCC (EVRP) to determine the
ranges of integer arguments.  The note they print shows the range they obtain
from it.  In this case the range is less than optimal.  GCC 11 adds a new range
engine (the Ranger) capable of computing more accurate ranges on demand.  The
Ranger hasn't been integrated with the strlen/sprintf pass yet but once it is,
I expect this warning to go away.  In the meantime, explicitly asserting just
before the snprintf that the argument is in the expected range avoids the
warning:

          if (num < 10) __builtin_unreachable ();
          snprintf (buf, 10, "%d", num);

as does casting the argument to an unsigned type.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
[Bug 85741] [meta-bug] bogus/missing -Wformat-overflow

[Bug tree-optimization/97628] format truncation false positive for O1 and mtune=nocona

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
if (num < 10) __builtin_unreachable ();
certainly not, I guess you meant
if (num < 0) __builtin_unreachable ();

[Bug tree-optimization/97628] format truncation false positive for O1 and mtune=nocona

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
Yes, I did mean 'if (num < 0) __builtin_unreachable ();' but as it turns out
that doesn't help in this case.  Casting to an unsigned type does and results
in the expected range [0, 9].

[Bug tree-optimization/97628] format truncation false positive for O1 and mtune=nocona

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
With the SSA_NAME_RANGE_INFO (i.e. when not using the GCC11+ ranger in the pass
or when it is done inside of the vrp passes) it matters whether there is some
SSA_NAME to stick the range to, the testcase doesn't modify the num in any way
in that if block so there is nothing to stick the [0, 9] range at.  Surprises
me it isn't just VARYING though (then the warning wouldn't trigger, right?).

[Bug tree-optimization/97628] format truncation false positive for O1 and mtune=nocona

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
Right, the warning only triggers for constrained ranges (i.e., not for
VARYING).  The argument the range comes from is a PHI:

 <ssa_name 0x7fffea9c60d8
    type <integer_type 0x7fffea8105e8 int sizes-gimplified public SI
        size <integer_cst 0x7fffea7f7f18 constant 32>
        unit-size <integer_cst 0x7fffea7f7f30 constant 4>
        align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea8105e8 precision:32 min <integer_cst 0x7fffea7f7ed0 -2147483648> max
<integer_cst 0x7fffea7f7ee8 2147483647> context <translation_unit_decl
0x7fffea9a44b0 /build/tmp/pr97628.c>
        pointer_to_this <pointer_type 0x7fffea8189d8>>
    visited var <parm_decl 0x7fffea9a8080 num>
    def_stmt num_93 = PHI <num_108(12), num_96(13)>
    version:93>