On 05/13/2018 03:00 PM, Marc Glisse wrote:
On Sun, 13 May 2018, Paul Smith wrote:
On Sun, 2018-05-13 at 15:53 -0400, Paul Smith wrote:
The first problem is that I have three instances (in a very large
codebase) where I'm seeing errors like this:
error: argument 1 value '18446744073709551615' exceeds maximum object
size 9223372036854775807 [-Werror=alloc-size-larger-than=]
...
I can disable this warning
Err... no I can't? Isn't there some way to keep -Wall but disable
-Walloc-size-larger-than? -Wno-alloc-size-larger-than is unrecognized
and -Walloc-size-larger-than=0 doesn't disable it...
??
It does seem harder to disable than it should be. File a PR?
In my opinion, just like -Wmaybe-uninitialized, it should not be in
-Wall but only -Wextra (except possibly when the statement
post-dominates the entry of a function that is not a clone, or some
similar constraint that avoids all the false positives due to
optimization artifacts).
-Wmaybe-uninitialized is in -Wall. It is also quite different
from -Walloc-size-larger-than: it's designed to trigger when
a variable may be used without being initialized, not when it
necessarily is used that way. The option exists not because
-Wuninitialized is prone to false positives but because it's
valuable to detect even cases where a variable is initialized
along one code path but not along another. I.e., the option
issues false positives by design.
-Walloc-size-larger-than, like most (all?) other middle-end
warnings, is designed to trigger only for calls that truly have
an argument in excess of the limit. Unlike -Wmaybe-uninitialized,
it is not intended to diagnose case where the argument may but
need not be excessive (i.e., it's not expected to have false
positives, and I don't think it is particularly prone to them).
The instances of false positives we have seen have been due
to optimizers such as jump threading introducing calls with
excessive argument values (typically SIZE_MAX). We have talked
about enhancing the responsible passes to avoid doing that (i.e.,
to recognize undefined/impossible calls and either avoid inserting
them or replace them with __builtin_trap/unreachable). Not just
to avoid the false positives but also to improve the emitted code.
Martin
