[Bug tree-optimization/98281] - -Wformat-truncation false positive due to excessive integer range (gcc 10.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98281 --- Comment #5 from ishikawa,chiaki --- (In reply to Martin Sebor from comment #3) > The warning works as designed but the range information it depends on is > less than perfect. As discussed in pr94021 that's a known limitation of the > current range propagation infrastructure. GCC 11 adds an improved range > engine known as the Ranger that's expected to remedy this but it is yet to > be integrated with the sprintf/strlen pass. The argument ranges can be > constrained by using a "narrower" directive such as %hhu. > Thank you for the detailed explanation. It would be great to see this Ranger incorporated into the sprintf/strlen pass. I say this because I found a bug in a popular code which this feature could have found. (The bug was found by the dynamic check done by ASAN-build.) Thank you for continuously developing GCC with these new features. Happy festive season to all.
[Bug tree-optimization/98281] - -Wformat-truncation false positive due to excessive integer range (gcc 10.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98281 --- Comment #4 from ishikawa,chiaki --- (In reply to Martin Sebor from comment #3) > The warning works as designed but the range information it depends on is > less than perfect. As discussed in pr94021 that's a known limitation of the > current range propagation infrastructure. GCC 11 adds an improved range > engine known as the Ranger that's expected to remedy this but it is yet to > be integrated with the sprintf/strlen pass. The argument ranges can be > constrained by using a "narrower" directive such as %hhu. > Thank you for the detailed explanation. It would be great to see this Ranger incorporated into the sprintf/strlen pass. I say this because I found a bug in a popular code which this feature could have found. (The bug was found by the dynamic check done by ASAN-build.) Thank you for continuously developing GCC with these new features. Happy festive season to all.
[Bug tree-optimization/98281] - -Wformat-truncation false positive due to excessive integer range (gcc 10.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98281
Martin Sebor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Martin Sebor ---
The warning works as designed but the range information it depends on is less
than perfect. As discussed in pr94021 that's a known limitation of the current
range propagation infrastructure. GCC 11 adds an improved range engine known
as the Ranger that's expected to remedy this but it is yet to be integrated
with the sprintf/strlen pass. The argument ranges can be constrained by using
a "narrower" directive such as %hhu.
A small test case that helps see what's going on is this:
$ gcc -O2 -S -Wall -fdump-tree-strlen-all=/dev/stdout pr98281.c
void f (char *d, int i)
{
if (i >= 3600 * 24 || i <= -3600 * 24)
return;
if (i < 0)
i = -i;
int h = i / 3600;
int m = (i - (h * 3600)) / 60;
int s = (i - (h * 3600) - (m * 60));
if (s > 0)
__builtin_snprintf (d, 9, "%c%02d%02d%02d", '+', h, m, s);
}
;; Function f (f, funcdef_no=0, decl_uid=1944, cgraph_uid=1, symbol_order=0)
...
Intersecting
int [-169140, 169199]
and
int [1, 169199]
to
int [1, 169199]
pushing new range for s_11: int [1, 169199] EQUIVALENCES: { s_11 } (1
elements) <<< last argument (s)
pr98281.c:13: snprintfD.977: objsize = 9, fmtstr = "%c%02d%02d%02d"
<<< snprintf call
Directive 1 at offset 0: "%c"
Result: 1, 1, 1, 1 (1, 1, 1, 1)
Directive 2 at offset 2: "%02d"
Result: 2, 2, 2, 2 (3, 3, 3, 3)
Directive 3 at offset 6: "%02d"
<<< last directive
Result: 2, 5, 5, 5 (5, 8, 8, 8)
<<< output between 2 and 5 bytes
Directive 4 at offset 10: "%02d"
pr98281.c: In function ‘f’:
pr98281.c:13:42: warning: ‘%02d’ directive output may be truncated writing
between 2 and 6 bytes into a region of size between 1 and 4
[-Wformat-truncation=]
13 | __builtin_snprintf (d, 9, "%c%02d%02d%02d", '+', h, m, s);
| ^~~~
pr98281.c:13:31: note: directive argument in the range [1, 169199]
13 | __builtin_snprintf (d, 9, "%c%02d%02d%02d", '+', h, m, s);
| ^~~~
Result: 2, 6, 6, 6 (7, 14, 14, 14)
Directive 5 at offset 14: "", length = 1
pr98281.c:13:5: note: ‘__builtin_snprintf’ output between 8 and 15 bytes into a
destination of size 9
13 | __builtin_snprintf (d, 9, "%c%02d%02d%02d", '+', h, m, s);
| ^
voidD.51 f (charD.7 * dD.1942, intD.6 iD.1943)
{
...
# RANGE [-169140, 169199]
<<< last argument (negative?)
s_11 = _4 + _6;
...
snprintfD.977 (d_13(D), 9, "%c%02d%02d%02d", 43, h_9, m_10, s_11);
...
}
*** This bug has been marked as a duplicate of bug 94021 ***
[Bug tree-optimization/98281] - -Wformat-truncation false positive due to excessive integer range (gcc 10.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98281 --- Comment #2 from ishikawa,chiaki --- Created attachment 49764 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49764=edit The patch that I had for 94021 Funny I thought this was gone for a while with gcc-9 and an earlier 10 (?) I say this because I had a patch as attached locally (which I produced since I reported bug 94021). But I could compile the source without the patch this Fall., it seems. Yeah, I took it out from my local patch queeu. Maybe something changed. Also, please notice that the first part of the patch is for the case quite similar to bug 94021 comment 4 test example, and I think that was somehow taken care of (?) Anyway, the bug(s) still persist for the static snprintf format check.
[Bug tree-optimization/98281] - -Wformat-truncation false positive due to excessive integer range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98281 --- Comment #1 from ishikawa,chiaki --- The command to compile the source file uploaded. (Place it in /tmp) cd tmp export TERM=dumb /usr/bin/gcc-10 -std=gnu99 -o /tmp/Unified_c_libical_src_libical1.o -c -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/system_wrappers -include /NEW-SSD/NREF-COMM-CENTRAL/mozilla/config/gcc_hidden.h -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -DDEBUG=1 -DHAVE_CONFIG_H -DHAVE_SNPRINTF -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -DSTATIC_EXPORTABLE_JS_API -I/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical -I/NEW-SSD/moz-obj-dir/objdir-tb3/comm/calendar/libical/src/libical -I/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/nspr -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/nss -fPIC -include /NEW-SSD/moz-obj-dir/objdir-tb3/mozilla-config.h -DMOZILLA_CLIENT -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -DUSEVALGRIND=1 -DDEBUG -g -gsplit-dwarf -Werror=sign-compare -Werror=unused-result -Werror=unused-variable -Werror=format -fuse-ld=gold -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe -g -g -Og -fvar-tracking -gdwarf-4 -fvar-tracking-assignments -freorder-blocks -fno-omit-frame-pointer -funwind-tables -Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wduplicated-cond -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wno-multistatement-macros -Wno-error=class-memaccess -Wno-error=deprecated-copy -Wformat -Wformat-overflow=2 -Werror=implicit-function-declaration -Wno-psabi -MD -MP -MF .deps/Unified_c_libical_src_libical1.o.ppUnified_c_libical_src_libical1.c We get the following error at the end, but please ignore it. Unified_c_libical_src_libical1.c: At top level: Unified_c_libical_src_libical1.c:48: fatal error: opening dependency file .deps/Unified_c_libical_src_libical1.o.pp: No such file or directory 48 | #pragma GCC visibility pop
