--- Comment #10 from steven at gcc dot gnu dot org 2010-04-14 18:04 ---
Yes, release checking is OK. And I don't think it is OK to have 90% of the
compile time spent on calculating debugging info, no matter how crazy the test
case may be. We should try to speed this up. But there are oth
--- Comment #9 from iains at gcc dot gnu dot org 2010-04-14 17:44 ---
(In reply to comment #8)
> Are you speaking of gcc/testsuite/gcc.dg/pr43058.c?
yes - as per Comments #4 and # 5, you will find that this is less troublesome
m64
(on the same machine 10x faster at m64 => I get around
--- Comment #8 from dominiq at lps dot ens dot fr 2010-04-14 17:34 ---
Iain,
Are you speaking of gcc/testsuite/gcc.dg/pr43058.c?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43753
--- Comment #7 from iains at gcc dot gnu dot org 2010-04-14 16:58 ---
(In reply to comment #5)
> The testcase is chosen to be quite large (and is expensive mainly for i?86
> -m32, not -m64), if it is much smaller than even unfixed gcc wouldn't start
> eating all available RAM. For me in
--- Comment #6 from iains at gcc dot gnu dot org 2010-04-14 16:56 ---
(In reply to comment #1)
> With checking enabled, anything can happen. Try without.
Hmm, OK I guess this is bogus - from the other comments - so I'll mark the bug
as resolved ...
.. .. but FWIW:
I rebuilt with rele
--- Comment #5 from jakub at gcc dot gnu dot org 2010-04-14 16:11 ---
The testcase is chosen to be quite large (and is expensive mainly for i?86
-m32, not -m64), if it is much smaller than even unfixed gcc wouldn't start
eating all available RAM. For me in high load it sometimes times o
--- Comment #4 from hjl dot tools at gmail dot com 2010-04-14 15:51 ---
On Intel Xeon X3350 2.66GHz with 8GB RAM, I got
[...@gnu-1 gcc]$ time ./xgcc -B./ -g -O2 -S
../../src-trunk/gcc/testsuite/gcc.dg/pr43058.c
real0m9.187s
user0m9.042s
sys 0m0.127s
[...@gnu-1 gcc]$ ./xgcc
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-14 15:48 ---
(In reply to comment #2)
> FWIW, there are so many "var-tracking is slow" bugs now, that one might
> reasonably question the QoI of it.
> See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
There has been muc
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-14 15:44 ---
FWIW, there are so many "var-tracking is slow" bugs now, that one might
reasonably question the QoI of it.
See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-14 15:41 ---
With checking enabled, anything can happen. Try without.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43753
10 matches
Mail list logo
