On 12/17/18 2:23 AM, Christophe Lyon wrote:
Hi,
On Thu, 13 Dec 2018 at 19:14, Jeff Law <l...@redhat.com> wrote:
On 12/12/18 4:18 PM, Martin Sebor wrote:
POSIX requires snprintf to fail with EOVERFLOW when the specified
bound exceeds INT_MAX. This requirement conflicts with the C
requirements on valid calls to the function and isn't universally
implemented (e.g., Glibc doesn't seem to follow it, and GCC has
historically not paid heed to it either). Nevertheless, there
are implementations that do respect it (Solaris being one of
them), and it seems that GCC should make a tricky situation
even more treacherous for programmers by returning different
values from some calls to the function than the library would.
This is also what bug 87096 requests. The patch also adds
a warning that was missing from a subset of these troublesome
calls.
The attached patch disables the snprintf constant folding and
range optimization for calls to it and other related bounded
functions when the bound is not known not to exceed INT_MAX.
Tested on x86_64-linux.
Martin
gcc-87096.diff
PR tree-optimization/87096 - Optimised snprintf is not POSIX conformant
gcc/ChangeLog:
PR rtl-optimization/87096
* gimple-ssa-sprintf.c (sprintf_dom_walker::handle_gimple_call): Avoid
folding calls whose bound may exceed INT_MAX. Diagnose bound ranges
that exceed the limit.
gcc/testsuite/ChangeLog:
PR tree-optimization/87096
* gcc.dg/tree-ssa/builtin-snprintf-4.c: New test.
This new test fails on arm (and other 32 bits targets according to
gcc-testresults)
FAIL: gcc.dg/tree-ssa/builtin-snprintf-4.c (test for warnings, line 106)
FAIL: gcc.dg/tree-ssa/builtin-snprintf-4.c (test for warnings, line 128)
FAIL: gcc.dg/tree-ssa/builtin-snprintf-4.c (test for warnings, line 74)
FAIL: gcc.dg/tree-ssa/builtin-snprintf-4.c (test for warnings, line 87)
FAIL: gcc.dg/tree-ssa/builtin-snprintf-4.c scan-tree-dump-times
optimized " = snprintf" 12
FAIL: gcc.dg/tree-ssa/builtin-snprintf-4.c scan-tree-dump-times
optimized " = vsnprintf" 12
The test assumed that PTRDIFF_MAX > INT_MAX. I adjusted it in
r267206 to avoid that assumption.
Thanks
Martin
