Bootstrap failure on Linux/x86-64

[Kenneth Zadeck]

Andreas Jaeger wrote:
> Andrew Pinski <pinskia@physics.uc.edu> writes:
>
>   
>> On Jan 21, 2006, at 1:09 PM, Andreas Jaeger wrote:
>>
>>     
>>> On Sat, Jan 21, 2006 at 12:42:24PM -0500, Andrew Pinski wrote:
>>>       
>>>> On Jan 21, 2006, at 12:38 PM, Andreas Jaeger wrote:
>>>>
>>>>         
>>>>> I'm still seeing this with current Subversion.  Anybody else having
>>>>> the same problem on x86-64?  It fails for me on the two systems I
>>>>> tested it on,
>>>>>           
>>>> What reversion is this on?
>>>>
>>>> This worked for me on 110050 and 110059.
>>>>         
>>> I'll try 110059 now to double check.  Perhaps my configure flags are
>>> the
>>> problem, I use:
>>> /cvs/gcc-svn/trunk/configure   --prefix=/opt/gcc/4.2-devel
>>> --enable-checking=misc,tree,gc,rtl,rtlflag,assert
>>> --enable-threads=posix --enable-clocale=gnu --enable-__cxa_atexit
>>> --enable-shared --with-system-zlib x86_64-suse-linux-gnu
>>> --enable-languages=c,ada,c++,fortran,java,objc,treelang
>>>       
>> I just used 110067 and it worked.  Maybe it is one of the checking
>> options you are
>> using which is causing it.  I just used the default checking.
>>     
>
> I now used 110067 with the default checking options - and it worked,
> so it's the checking options.
>
> Kenneth, Zdenek, could you look into this?  Please use the same
> checking options that I have above.
>
>   
>> Let me double check with the checking you have.
>>     
>
> Thanks,
> Andreas
>   
I am not going to see this failure on my machine.  I have a 2gb x86-64 
which will easily handle
compiling this size file.   I was watching top as it compiled a stage2 
insn-addrtab, which I think is the largest function in the gcc stack and 
the VIRT topped at 501mb, which is no sweat for this machine.  You could 
argue, (and I would not disagree with you) that 501mb is not tolerable 
and is symptomatic of something bad happening.  There are, most likely 
storage leaks in the system.  But I do not think that you are going to 
necessarily find the problem by looking to see which version happens to 
crash on your machine.  The worst case senario is that this is just 
footprint creep and the version that failed was just the one the added 
the straw that broke the camels back with you particular config.

I am not fully into building stage3 and have no failure.

btw, I am doing this with the latest baseline compiler.  I can go back 
to earlier compilers if you want.  But given that andreas's failed with 
the following line:
cc1: out of memory allocating 22752576 bytes after a total of 142843904 bytes

I am not going to see the problem.

Kenny