https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79257
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-01-28
Ever confirmed|0 |1
--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
A few more comments:
1) moving the gimple-ssa-sprintf pass after vrp2 suppresses just one of the two
warnings (the argument in the second call to sprintf is still in the same
range)
2) it's not the null pointer sanitizer that's causing the warnings but rather
the integer overflow sanitizer
3) the warnings don't seem related to r244974 (i.e., the range of the argument
is the same and the same warnings are still issued)
4) similar warnings are issued prior to the recent changes committed to resolve
bug 78703 so it's not a recent change or regression
5) the warning is issued on the basis that the range of the argument values is
a subrange of its type (as opposed to one whose value is completely unbounded,
such a function argument); i.e., an attempt has been made to constrain the
argument, presumably to make it fit in the buffer, but the attempt doesn't go
far enough
It's worth noting that this problem isn't specific to the -Wformat-overflow
warning. It affects all get_range_info clients outside VRP that use the upper
bound of the range (I think that's just -Walloca-larger-than in GCC 7, but the
list is likely to grow in the future).
Ideally, the range info would be as accurate outside VRP as within it. Barring
that, the range info consumers might need to be more closely integrated with
the VRP pass in some way as Richard suggests.
I'm not sure what's the appropriate solution for GCC 7. Relaxing the logic in
the -Wformat-{overflow,truncation} checker to avoid this instance of the
warning will cause false negatives and won't do anything for the other
warning(s). Disabling the warning altogether when -fsanitize=undefined is
specified also doesn't seem like a good fix.
I would tend to defer the decision until more code has been exposed to the
warning (the Fedora mass rebuild). If this turns out to be a pervasive problem
it's easy to implement one of the changes above. It it's rare living with it
would seem like an acceptable tradeoff. In GCC 8 I'd like to look into
improving the warning to avoid this case as well as a number of others we know
about.
