Andreas Jaeger wrote:
Andrew Pinski <[EMAIL PROTECTED]> 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
