Hi Martin,
> 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.
there's still something wrong with that testcase:
* It XPASSes on i386-pc-solaris2.11 with -m64:
XPASS: gcc.dg/tree-ssa/builtin-snprintf-6.c scan-tree-dump-times optimized
"Function test_assign_aggregate" 1
It's almost always wrong to only handle x86_64; you need to consider
i?86 && lp64, too.
* Even after your patch, there are several gcc-testresults postings
showing the test to XPASS on x86_64-pc-linux-gnu. I haven't looked
closer yet.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
