This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/85175] [8 regression] false-positive -Wformat-overflow= warning with gcc-8 -Os


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85175

--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
In general, sizing buffers for the minimum/maximum value of each directive's
argument and choosing the appropriate length modifiers (e.g., %hhi for char or
%hi for short) avoids these problems.

The thinking behind the current behavior at level 1 is that an expression in
some known range is a sign that the programmer may have made an effort to
constrain the value, while an expression for which we have no range information
may have been constrained and we just don't see it.  When the known range
doesn't constrain the value sufficiently, the warning triggers.  An unknown
range doesn't.  The "fix" for a warning in the former case should in most cases
be to simply constrain the variable either by using an appropriate length
modifier in the directive or just before the call (e.g., via some form of an
assertion or an equivalent of '((x < min || x > max) ? __builtin_unreachable ()
: (void)0).   This works quite well except when the buffer is just big enough
and when the warning exposes weaknesses in optimizations and/or unforeseen
interactions with other transformations (usually jump-threading or the
sanitizers).  Rather than weakening the warnings our approach to these problems
has been to improve the optimizers.  I'm hoping this case can be dealt with the
same way but I'm not familiar enough with the EVRP machinery yet to tell if
that will be possible.

As for -Wformat-overflow=2, an expression in an unknown range is treated as if
it had the maximum range of its type.

(I suppose we should also have level 3 where ranges are ignored and buffers are
expected to be sized only according to argument type.  I realize it's not what
you're looking for but it would make it straightforward to write safe,
warning-free code regardless of optimizations.)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]