On 05/13/2018 01:53 PM, Paul Smith wrote:
> Hi all.
>
> I'm testing my codebase with GCC 8.1 (built myself) and am running into
> a couple if issues. Note I was able to compile and run OK with GCC 7.3
> FYI. This is on a GNU/Linux x86_64 system and I'm using binutils 2.30,
> and compiling with -O2 -g -Wall -Werror (and a few other things).
>
> 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=]
>
> These instances all have a similar invocation model either directly or
> indirectly (through inline functions for example) which involves a
> size_t value as an argument to operator new[] which is overridden as an
> inline function that calls malloc(), and the value is involved in some
> condition operation regarding its value.
>
> Here's a simple pseudo-example:
>
> SortRecord::sortRecord(size_t numberValues)
> {
> values = (numberValues == 0 ? nullptr : new Value[numberValues]);
> ...
>
> Clearly if numberValues is large enough this allocation must fail but I
> don't see how or why GCC is warning me about this, or what I'm supposed
> to do about it.
>
> If I (just to test) remove the condition then it compiles fine:
>
> SortRecord::sortRecord(size_t numberValues)
> {
> values = new Value[numberValues];
> ...
>
> Also, if I don't have the inline operator new[] then it seems to
> compile OK as well. The inline version is pretty straightforward:
>
> operator new[](size_t sz) {
> void* p = malloc(sz);
> if (!p) MemFail();
> return p;
> }
>
> (basically).
>
> I can disable this warning but I wonder if this is a bug in GCC or this
> warning is just too aggressive. Unfortunately I can't point to the
> real code and I don't have a cut-down example right now.
We'd really need to see the full testcase. It'd be best to open a new
bug and attach the testcase to the bug.
Most commonly this occurs because there's a path to the allocation where
the size could be -1. Without a full testcase there's no way for us to
verify that such a path exists, whether or not it is a truly viable path
through the CFG.
Jeff
