In case anyone is following along, any potential work on this is now being tracked by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85795 Cheers (and thanks Martin!) On Mon, 2018-05-14 at 17:24 -0400, Paul Smith wrote: > After an entirely too-long time spent futzing with this I managed to > produce a small test sample. Bug filed. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783 > > On Mon, 2018-05-14 at 09:48 -0600, Jeff Law wrote: > > 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.
