GCC 8.1: alloc-size-larger-than warnings during operator new[]

[Jeff Law]

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