On 8/27/19 4:34 PM, Martin Sebor wrote: > The recent sprintf+strlen integration doesn't handle unbounded > string lengths entirely correctly for ILP32 targets and causes > -Wformat-overflow false positives in some common cases, including > during GCC bootstrap targeting such systems The attached patch > fixes that mistake. (I think this code could be cleaned up and > simplified some more but in the interest of unblocking the ILP32 > bootstrap and Glibc builds I haven't taken the time to do that.) > The patch also adjusts down the maximum strlen result set by EVRP > to PTRDIFF_MAX - 2, to match what the strlen pass does. > > The strlen maximum would ideally be computed in terms of > max_object_size() (for which there would ideally be a --param > setting), and checked the same way to avoid off-by-one mistakes > between subsystems and their clients. I have not made this change > here but added a FIXME comment mentioning it. I plan to add such > a parameter and use it in max_object_size() in a future change. > > Testing with an ILP32 compiler also ran into the known limitation > of the strlen pass being unable to determine the length of array > members of local aggregates (PR 83543) initialized using > the braced-list syntax. gcc.dg/tree-ssa/builtin-snprintf-6.c > fails a few cases as a result. I've xfailed the assertions > for targets other than x86_64 where it isn't an issue. > > Martin > > gcc-91567.diff > > PR tree-optimization/91567 - Spurious -Wformat-overflow warnings building > glibc (32-bit only) > > gcc/ChangeLog: > > PR tree-optimization/91567 > * gimple-ssa-sprintf.c (get_string_length): Handle more forms of lengths > of unknown strings. > * vr-values.c (vr_values::extract_range_basic): Set strlen upper bound > to PTRDIFF_MAX - 2. > > gcc/testsuite/ChangeLog: > > PR tree-optimization/91567 > * gcc.dg/tree-ssa/builtin-snprintf-6.c: Xfail a subset of assertions > on targets other than x86_64 to work around PR 83543. > * gcc.dg/tree-ssa/builtin-sprintf-warn-22.c: New test. OK. I'm not sure this will fix the glibc issue (it looked like it was unrelated to ILP32 to me).
jeff
