successfully bootstrapped 4.3.3 from 4.3.1-1ubuntu2
boo...@bootch-desktop:~/gcc-4.3.3.obj$ # boo...@bootch-desktop:~/gcc-4.3.3.obj$ #Successfully built and installed gcc-4.3.3: boo...@bootch-desktop:~/gcc-4.3.3.obj$ date Sat Apr 11 09:32:41 EDT 2009 boo...@bootch-desktop:~/gcc-4.3.3.obj$ pwd /home/bootch/gcc-4.3.3.obj boo...@bootch-desktop:~/gcc-4.3.3.obj$ ../gcc-4.3.3/config.guess i686-pc-linux-gnu boo...@bootch-desktop:~/gcc-4.3.3.obj$ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.3/configure Thread model: posix gcc version 4.3.3 (GCC) boo...@bootch-desktop:~/gcc-4.3.3.obj$ # I built all languages boo...@bootch-desktop:~/gcc-4.3.3.obj$ more /etc/issue Ubuntu 8.10 \n \l boo...@bootch-desktop:~/gcc-4.3.3.obj$ uname -a Linux bootch-desktop 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686 GNU/Linux boo...@bootch-desktop:~/gcc-4.3.3.obj$ dpkg -l libc6 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii libc6 2.8~20080505-0 GNU C Library: Shared libraries boo...@bootch-desktop:~/gcc-4.3.3.obj$ # I used smp multithreaded: make -j 2 boo...@bootch-desktop:~/gcc-4.3.3.obj$ #
Re: [cond-optab] svn branch created, looking for reviews for the "cleanup" parts
Uros Bizjak wrote: I created the cond-optab svn branch and finished committing the cond-optab patches to it. I also documented it in svn.html. To aid testing, I'd like people to help bootstrapping bootstrappable targets -- arm, alpha, ia64, pa, s390, x86_64. I can bootstrap on CompileFarm alpha machine. Unfortunatelly, the machine ran out of disk space, so I'm actually waiting for a quota update to re-run the bootstrap. Added Laurent to Cc. Paolo, bootstrap finished OK on alpha, regression test results are at [1]. There are unrelated errors with "random" libc++ tests and HJ's PR39323 testcase. Do not mind the timeouts. [1] http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01146.html Uros.
Re: The gcc-in-cxx branch now completes bootstrap
>> Also, is there any significant difference in bootstrap times?
>
> I haven't actually measured, but subjectively bootstrap does seem to
> take longer.
I tried this out of curiosity. The numbers below are the bootstrap times on
a 64bit 2.6.28 Linux system (Core 2 E8400), building single threaded with
--enable-languages=c,c++ --disable-multilib
Regular gcc:
real59m6.914s
user53m53.702s
sys 3m24.073s
gcc-in-cxx:
real68m15.366s
user61m32.255s
sys 4m24.481s
Of course the bootstrap times are not that useful themselves, as they
compare two quite different compilation tasks (one C, one C++). To get a
better idea about the different compiler speeds, I compiled some random
(reasonably complex) C++ code I had at hand, and compared the compile times.
Regular gcc:
real0m30.478s
user0m27.842s
sys 0m1.888s
gcc-in-cxx:
real0m35.926s
user0m34.386s
sys 0m1.208s
Again the comparison is not 100% fair ("regular gcc" is current mainline,
while the gcc-in-cxx branch is older), but apparently the C++ version is
quite a bit slower.
Admittedly gcc-in-cxx just recently managed to bootstrap at all, so perhaps
performance comparisons are a bit unfair. But I do not mean this as critique
of gcc-in-cxx, I want to help improve it and to bring it to the same speed
as regular mainline.
Is there any reasonably simple way to find out why the C++ version is
slower? I can use something like oprofile, of course, but I thought gcc can
somehow give statistics about its internal times, which might be more useful
for a first approximation.
Thomas
Re: The gcc-in-cxx branch now completes bootstrap
Is there any reasonably simple way to find out why the C++ version is slower? I can use something like oprofile, of course, but I thought gcc can somehow give statistics about its internal times, which might be more useful for a first approximation. I think you're thinking about the -Q option? Segher
Re: My plans on EH infrastructure
> 2009/4/8 Sylvain Pion : > > > Maybe, but for exceptions which are relatively local, say, inside a given > > library, the user can assume that GCC has switched to the "local ABI" with > > fast internal exceptions, since he may have compiled the library as one > > translation unit, so he may be able to control the possible scope of the > > exceptions. And so he may be able to make a good guess about what the > > costs will be. > > My application has this property, but again, maybe it's only me. > > You are not alone. I've seen people refrain from using exceptions > (which provide better support for error report and recovery, compared to > alternatives) because the compilers they were using did not exploit > available local information. Other compilers, you've mention, do however > optimize accordingly. I think it would be great if GCC could be made Can you be more specific about what optimizations other compilers do in this area that would be useful in GCC? Honza > competitive in that area. > > -- Gaby
Re: cleanup tests failing on MIPS64
Adam Nemet writes: > For two testresults now the cleanup tests are failing in both gcc and g++: > > http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01031.html > http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg00592.html > > I waited for another testresults because there were some bug fixes in this > area after the eh changes. > > Does somebody know what's going on? I'll look at it otherwise. I am not exactly sure what has exposed this but the bug seems to be old. can_throw_external in except.c does not look at the branch delay slot (second entry in a SEQUENCE) to determine whether the insn may throw or not. In gcc.dg/cleanup-8.c for example after inlining fn3, the trapping store is moved to the delay slot of abort, which is a nothrow function so we decide that fn2 can't throw and then ultimately remove the eh region around fn1 in fn0. Adam
Re: The gcc-in-cxx branch now completes bootstrap
On Sat, 2009-04-11 at 22:37 +0200, Thomas Neumann wrote: > Is there any reasonably simple way to find out why the C++ version is > slower? I can use something like oprofile, of course, but I thought > gcc can somehow give statistics about its internal times, which might > be more useful for a first approximation. Try using -ftime-report. Ben
Re: cleanup tests failing on MIPS64
Adam Nemet writes: > I am not exactly sure what has exposed this but the bug seems to be old. > can_throw_external in except.c does not look at the branch delay slot (second > entry in a SEQUENCE) to determine whether the insn may throw or not. > > In gcc.dg/cleanup-8.c for example after inlining fn3, the trapping store is > moved to the delay slot of abort, which is a nothrow function so we decide > that fn2 can't throw and then ultimately remove the eh region around fn1 in > fn0. I forgot to mention that I started testing a patch. Adam
Re: The gcc-in-cxx branch now completes bootstrap
Ben Elliston wrote: > Try using -ftime-report. thanks, that was what I had in mind. The largest difference seems to be in "tree STMT verifier" (36% runtime increase), a few others increased slightly, most seem to be nearly identical. (This distribution could be an artifact of my example code, of course). I will have to take a closer look to find the exact cause of the slow-down. Thomas
