[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374 --- Comment #7 from Jakub Jelinek --- Bisection shows that first in r12-5014-g6b8b959675a3e14cfdd2145bd62e4260eb193765 we started to warn on both f and g in #c5 at -O0 -Wall, and then since r12-7870-g28c5df79300ab354cbc381aab200f7c2bd0331ad it only warns in f and not in g anymore.
[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374 Jakub Jelinek changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Seems format_integer uses the ranger even at -O0, and asks the ranger there (talking about #c5 at -O0 -Wall) for value of loop.0_1 1398 value_range vr; 1399 ptr_qry.rvals->range_of_expr (vr, arg, dir.info->callstmt); in : loop_4 = 1; : # loop_2 = PHI loop.0_1 = loop_2; loop_6 = loop.0_1 + 1; __builtin_snprintf (, 11, "%d", loop.0_1); if (loop_6 <= 9) goto ; [INV] else goto ; [INV] : goto ; [100.00%] and ranger says [irange] int [-2147483647, 9] Haven't checked if it just for -O0 doesn't look outside of the loop or what, not looking outside of the loop would give [-2147483648, 9] IMHO though. Anyway, in g it is asked about old_5 in: : loop_3 = 1; : # loop_1 = PHI old_5 = loop_1; loop_6 = loop_1 + 1; __builtin_snprintf (, 11, "%d", old_5); if (loop_6 <= 9) goto ; [INV] else goto ; [INV] : goto ; [100.00%] and returns [irange] int [1, 9] in that case.
[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-03-18
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||pinskia at gcc dot gnu.org
--- Comment #5 from Andrew Pinski ---
Confirmed.
For some reason doing changing `loop++` to what it does manually does not warn:
That is for
```
void f() {
char buf[11];
int loop(1);
do {
__builtin_snprintf(buf,sizeof(buf),"%d",loop++);
} while(loop<10);
}
void g() {
char buf[11];
int loop(1);
do {
int old = loop;
loop++;
__builtin_snprintf(buf,sizeof(buf),"%d",old);
} while(loop<10);
}
```
f is being warned about but g is not.
[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374
--- Comment #4 from Torsten Mandel ---
E.g.:
#include "stdio.h"
#include
int main() {
char buf[11];
int loop(1);
do {
snprintf(buf,sizeof(buf),"%d",loop++);
} while(loop<10);
}
[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374 --- Comment #3 from Torsten Mandel --- Sorry, actually it also triggers for values below LONG_MAX on gcc-12 & gcc-13 so it also works without UB which should not be the case.
[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374 --- Comment #2 from Torsten Mandel --- No, it only happens on overflow, although diagnostic behavior would still be inconsistent regarding the ++loop and the loop++ case.
[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374 Richard Biener changed: What|Removed |Added Summary|[12/13 Regression] snprintf |[12/13/14 Regression] |Wformat-truncation |snprintf Wformat-truncation Target Milestone|--- |12.4 --- Comment #1 from Richard Biener --- You are invoking UD so a diagnostic is within that constraint. Can you produce a testcase without UD that still shows the issue?
