public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/94021] -Wformat-truncation false positive due to excessive integer range
       [not found] <bug-94021-4@http.gcc.gnu.org/bugzilla/>
@ 2020-12-17 17:14 ` msebor at gcc dot gnu.org
  2021-01-04 15:34 ` amacleod at redhat dot com
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 4+ messages in thread
From: msebor at gcc dot gnu.org @ 2020-12-17 17:14 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #8 from Martin Sebor <msebor at gcc dot gnu.org> ---
*** Bug 98281 has been marked as a duplicate of this bug. ***

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug tree-optimization/94021] -Wformat-truncation false positive due to excessive integer range
       [not found] <bug-94021-4@http.gcc.gnu.org/bugzilla/>
  2020-12-17 17:14 ` [Bug tree-optimization/94021] -Wformat-truncation false positive due to excessive integer range msebor at gcc dot gnu.org
@ 2021-01-04 15:34 ` amacleod at redhat dot com
  2023-04-14  5:48 ` ishikawa at yk dot rim.or.jp
  2023-06-21  4:33 ` pinskia at gcc dot gnu.org
  3 siblings, 0 replies; 4+ messages in thread
From: amacleod at redhat dot com @ 2021-01-04 15:34 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jakub Jelinek from comment #6)
> CCing Andrew and Aldy to see what the ranger does or can do, talking about
>  I mean, if we have:
>   h_1 = x_2 / 3600;
>   if (x_2 <= -3599 && x_2 <= 89999)
>     use (h_1);
> figure out that h_1 is set to x_2 / 3600 and even when that
> SSA_NAME_DEF_STMT is not in a guarded block, its use is in one and so from
> the [-3599, 89999] range of x_2 at the point of use derive that h_1 there is
> [0, 24]?
> Surely if it is like:
>   if (x_2 <= -3599 && x_2 <= 89999)
>     {
>       h_1 = x_2 / 3600;
>       use (h_1);
>     }
> I'd expect it to handle it that way.


Certainly we get the latter case.  The earlier case is currently...
inconsistent.  Something I hope to address in the next release.

if we have precisely:
   h_1 = x_2 / 3600;
   if (x_2 <= -3599 && x_2 <= 89999)
     use (h_1);
and if that is calculated in such a way that all of the conditions are
evaluated in a single basic block, then the GORI engine well mark h1 and x_2
both as exports and the evaluator will calculate the desired value for h_1.

Once we start to pull them further apart, the current implementation loses the
ability to recalculate h_1 when we get new ranges for x_2.

I have plans to segregate the def chains from the export lists in blocks, and
allow for greater ability to recalculate things like this.

When I look at #c4 in EVRP, I see:
=========== BB 4 ============
    <bb 4> :
    # x_10 = PHI <x_13(D)(2), x_14(3)>
    h_15 = x_10 / 3600;
    _1 = x_10 % 3600;
    m_16 = _1 / 60;
    h.0_2 = (unsigned int) h_15;
    _3 = h.0_2 > 23;
    _5 = _3;
    if (_5 != 0)
      goto <bb 6>; [INV]
    else
      goto <bb 5>; [INV]

_1 : int [0, 3599]
h.0_2 : unsigned int [0, 596523]
x_10 : int [0, +INF]
h_15 : int [0, 596523]
m_16 : int [0, 59]
4->6  (T) h.0_2 :       unsigned int [0, 596523]
4->6  (T) _5 :  _Bool [1, 1]
4->6  (T) x_10 :        int [0, +INF]
4->6  (T) h_15 :        int [0, 596523]
4->5  (F) h.0_2 :       unsigned int [0, 596523]
4->5  (F) _5 :  _Bool [0, 0]
4->5  (F) x_10 :        int [0, +INF]
4->5  (F) h_15 :        int [0, 596523]

and then later on:
=========== BB 8 ============
x_10    int [0, +INF]
    <bb 8> :
    if (x_10 <= 89999)
      goto <bb 9>; [INV]
    else
      goto <bb 10>; [INV]

8->9  (T) x_10 :        int [0, 89999]
8->10  (F) x_10 :       int [90000, +INF]

=========== BB 9 ============
    <bb 9> :
    __builtin_snprintf (&a, 8, "%s%02i%02i", "+", h_15, m_16);


The defchains already indicate that h_15 is dependant on the value of x_10, and
I am hoping to enable recalculation of h_15 when a dependant range has
changed.. and not just when they are exported from the same block.

 so in this case, when we ask for the range of h_15 in BB_9, we should be able
to see that x_10 has a range of int [0, 89999] and trigger a recalculation of
h_15 using "current" values. and come up with h_15 = [0,24] 

The pieces are all there, but they need to be assembled in a non time consuming
way :-)

It is on the radar for next release.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug tree-optimization/94021] -Wformat-truncation false positive due to excessive integer range
       [not found] <bug-94021-4@http.gcc.gnu.org/bugzilla/>
  2020-12-17 17:14 ` [Bug tree-optimization/94021] -Wformat-truncation false positive due to excessive integer range msebor at gcc dot gnu.org
  2021-01-04 15:34 ` amacleod at redhat dot com
@ 2023-04-14  5:48 ` ishikawa at yk dot rim.or.jp
  2023-06-21  4:33 ` pinskia at gcc dot gnu.org
  3 siblings, 0 replies; 4+ messages in thread
From: ishikawa at yk dot rim.or.jp @ 2023-04-14  5:48 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #10 from ishikawa,chiaki <ishikawa at yk dot rim.or.jp> ---
It would be great if the problem is fixed in later versions.
I observe the error with gcc-12 on my computer yet.

*BUT* compiling with -O instead of -O2 succeeds !?

gcc-12 version.

gcc-12 (Debian 12.2.0-14) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

No error with -O !?

ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ gcc-12 -c -O -Wall /tmp/pr94021.c

Error with -O2 as before.

ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ gcc-12 -c -O2 -Wall /tmp/pr94021.c
/tmp/pr94021.c: In function ‘format_utc_offset’:
/tmp/pr94021.c:14:45: warning: ‘%02i’ directive output may be truncated writing
2 bytes into a region of size between 1 and 5 [-Wformat-truncation=]
   14 |     __builtin_snprintf (a, sizeof a, "%s%02i%02i", "+", h, m);
      |                                             ^~~~
/tmp/pr94021.c:14:38: note: directive argument in the range [0, 59]
   14 |     __builtin_snprintf (a, sizeof a, "%s%02i%02i", "+", h, m);
      |                                      ^~~~~~~~~~~~
/tmp/pr94021.c:14:5: note: ‘__builtin_snprintf’ output between 6 and 10 bytes
into a destination of size 8
   14 |     __builtin_snprintf (a, sizeof a, "%s%02i%02i", "+", h, m);
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug tree-optimization/94021] -Wformat-truncation false positive due to excessive integer range
       [not found] <bug-94021-4@http.gcc.gnu.org/bugzilla/>
                   ` (2 preceding siblings ...)
  2023-04-14  5:48 ` ishikawa at yk dot rim.or.jp
@ 2023-06-21  4:33 ` pinskia at gcc dot gnu.org
  3 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-06-21  4:33 UTC (permalink / raw)
  To: gcc-bugs

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |13.0

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
GCC 13:
  # RANGE [irange] int [0, 59] NONZERO 0x3f
  m_10 = _1 / 60;
  # RANGE [irange] int [0, 24] NONZERO 0x1f
  h_9 = _5 / 3600;

GCC 12:
  # RANGE [0, 59] NONZERO 63
  m_10 = _1 / 60;
  # RANGE [0, 596523] NONZERO 1048575
  h_9 = _5 / 3600;

And the warning is gone in GCC 13 too.

And produces:
/app/example.cpp:14: snprintfD.1756: objsize = 8, fmtstr = "%s%02i%02i"
  Directive 1 at offset 0: "%s"
    Result: 1, 1, 1, 1 (1, 1, 1, 1)
  Directive 2 at offset 2: "%02i"
    Result: 2, 2, 2, 2 (3, 3, 3, 3)
  Directive 3 at offset 6: "%02i"
    Result: 2, 2, 2, 2 (5, 5, 5, 5)
  Directive 4 at offset 10: "", length = 1
  Substituting 5 for return value.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-06-21  4:33 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-94021-4@http.gcc.gnu.org/bugzilla/>
2020-12-17 17:14 ` [Bug tree-optimization/94021] -Wformat-truncation false positive due to excessive integer range msebor at gcc dot gnu.org
2021-01-04 15:34 ` amacleod at redhat dot com
2023-04-14  5:48 ` ishikawa at yk dot rim.or.jp
2023-06-21  4:33 ` pinskia at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).