[PATCH] more warning code refactoring

Martin Sebor msebor@gmail.com
Thu Aug 19 16:30:01 GMT 2021

On 8/19/21 9:03 AM, Martin Sebor wrote:
> On 8/18/21 11:56 PM, Kewen.Lin wrote:
>> Hi David,
>> on 2021/8/19 上午11:26, David Edelsohn via Gcc-patches wrote:
>>> Hi, Martin
>>> A few PowerPC-specific testcases started failing yesterday on AIX with
>>> a strange failure mode: the compiler runs out of memory.  As you may
>>> expect from telling you this in an email reply to your patch, I have
>>> bisected the failure and landed on your commit.  I can alternate
>>> between the previous commit and your commit, and the failure
>>> definitely appears with your patch, although I'm unsure how your patch
>>> affected memory allocation in the compiler.  Maybe moving the code
>>> changed a type of allocation or some memory no longer is being freed?
>> To get rid of GTY variable alloc_object_size_limit looks suspicious,
>> maybe tree objects returned by alloc_max_size after the change are out
>> of GC's tracking?
>> If the suspicion holds, the attached explorative diff may help.
> I wouldn't expect that to make a difference.  There are thousands
> of similar calls to build_int_cst() throughout the middle end.
> Looking at the original patch, the change that I'm not sure about
> and that shouldn't have been part of the refactoring is the call
> to enable_ranger() in pass_waccess::execute().  It's something
> I was planning to do next.  But even that I wouldn't expect to
> eat up a whole 1GB or memory.

I have reproduced the excessive memory consumption with
the rlwimi-0.c test and a powerpc-linux cross-compiler, and
confirmed that it is indeed caused by the call to enable_ranger().
The test defines some six thousand functions so it seems that
unless each call enable_ranger() is paired with some call to
release the memory it allocates the memory leaks.

The removal of the alloc_object_size_limit global variable doesn't
have any effect on the test case.  The function that used it (and
now calls build_int_cst () instead) isn't called when the test
is compiled  (It's only called for calls to allocation functions
in the source and the test case has none.

Let me take care of releasing the ranger memory.


>> BR,
>> Kewen
>>> Previously, compiler bootstrap and all testcases ran with a data size
>>> of 1GB.  After your change, the data size required for those
>>> particular testcases jumped to 2GB.
>>> The testcases are
>>> gcc/testsuite/gcc.target/powerpc/rlwimi-[012].c
>>> The failure is
>>> cc1: out of memory allocating 65536 bytes after a total of 1608979296
>>> This seems like a significant memory use regression.  Any ideas what 
>>> happened?
> Not really.  The patch just moved code around.  I didn't make any
> changes that I'd expect to impact memory allocation to an appreciable
> extent, at least not intentionally.  Let me look into it and get back
> to you.
> Martin
>>> Thanks, David

More information about the Gcc-patches mailing list