Re: build gcc with distcc
Hi, > > My question is: how to build gcc bootstrap with distcc correctly. > > I believe it is impossible in the general case. bootstrap means to > compile GCC source code with a GCC compiler just built from the same > source code. Hence, to distribute this compilation with distcc, you'll > need to send the (stage1 compiled) GCC binaries on the network, and > distcc is not able to send binary programs. (If you'll extend distcc > to send binary programs - a non trivial task -, you open a new can of > worms, and you'll need to tackle potential security issues). Not impossible, you'd just need to have the different machines see/mount the same file-system for starters. That would result in coherent binaries, no shipping required. I've done this on an ancient x86 FreeBSD cluster (8 to 16 machines) mounting a single file server before with no hiccups. (That was gcc-3.4.0, ccache 2.2, distcc 2.13, both old). > So a distributed build has to also distribute files, for example by > sharing a common distributed file system. OF course details are > complex. On a somewhat related note, I'd be interested to hear if ccache could be snuck into bootstrapping to speed up recompiles in the intermediate stages, especially with incremental changes. (Anyone tried this?) I've noted that ccache-ing only speeds up the first stage, as one would expect. There might be a subtle issue with ccache assuming that the compiler that created a cache-hit object did not change. I'm only aware of ccache verifying compiler versions (string compare) in the hit-check, which alone doesn't suffice to guarantee that the cache is (or should be) hit. *sigh* Bootstrapping on me 5+ yr. old dual-G4 takes quite a while, even with make -j2 (which helps a lot). Wish-list: gcj-ccache for classpath rebuild acceleration. Fang
Re: build gcc with distcc
I forgot to mention IceCream http://en.opensuse.org/Icecream
which could be an alternative do distcc (that I didn't use yet).
PS On Debian, the packages are icecc [distributed compiler (client and
server)] & icecc-monitor because there the icecream package is a radio
stream download utility.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: build gcc with distcc
David Fang writes: > > *sigh* Bootstrapping on me 5+ yr. old dual-G4 takes quite a while, even > with make -j2 (which helps a lot). Wish-list: gcj-ccache for classpath > rebuild acceleration. What would it do? Andrew.
libjava install fails on hppa2.0w-hp-hpux11.00 / wrong install sequence
I failed to boostrap gcc-4.2.0 with libjava enabled for hppa2.0w-hp-hpux11.00. Bootstrap fails during installation of libjava. I tracked it down to install sequence issue. Components (jv-convert, gij, ...) which require libgcj, libgij, ... are installed before the libraries are installed. On Linux this produces only some warnings: libtool: install: warning: `libgcj.la' has not been installed ... On systems which require relink during install this fails: xgcc: /SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install/lib/libgcj.sl: No such file or directory libtool: install: error: relink `libjvm.la' with the above command before installing it Rainer Mit freundlichen Grüßen/Best Regards Dipl.-Ing. Rainer Emrich Leiter IT/Softwareentwicklung TECOSIM Technische Simulation GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49 (0) 6142 8272 - 12 Mobile: +49 (0) 163 56 949 - 20 Fax.: +49 (0) 6142 8272 - 49 www.tecosim.com best partner for simulation signature.asc Description: OpenPGP digital signature
Re: build failure, GMP not available
On Thu, 16 Nov 2006, Matt Fago wrote: > I have been struggling with this issue, and now that I have > successfully built GCC I thought I would share my results. Hopefully > it can help someone better versed in autotools to improve the build > of GCC with GMP/MPFR. > > For reference, a few older threads I've found: > http://gcc.gnu.org/ml/gcc/2006-01/msg00333.html";>http:// > gcc.gnu.org/ml/gcc/2006-01/msg00333.html > http://gcc.gnu.org/ml/gcc-bugs/2006-03/ > msg00723.html">http://gcc.gnu.org/ml/gcc-bugs/2006-03/msg00723.html > > The long and short of it: my builds of the latest versions of GMP and > MPFR were perfectly fine, although not ideal for building GCC. > However, the GCC 4.1.1 configure script incorrectly decided that it > _had_ located useful copies of GMP and MPFR, while in fact the > GFortran build fails 90 minutes later with the error message (as in > the second thread above): Thanks for the report. I believe some of your issues can be addressed. I'll add what I can to my TODO list. However I don't know if anything will be done for the 4.1.x series given the restriction for regression fixes only. I guess it depends on your definition of "regression", these problems have always existed since we started relying on gmp/mpfr in 4.0. However the 3.4 series didn't need these libraries so it never had these kind of problems building fortran. :-) It may be possible to get something into 4.2 since it hasn't been released yet. > One issue here is that '--with-mpfr=path' assumes that 'libmpfr.a' is > in 'path/lib' (not true for how I installed it), while '--with-mpfr- > dir=path' assumes that 'libmpfr.a' is in 'path', rather than > 'path/.libs' (can this work for anyone?). Note that '--with-gmp- > dir=path' does look in 'path/.libs'. This problem appears in the 4.0 series all the way through current mainline. I do believe it should be fixed and it is simple to do so. I'll take care of it. > My comments: > > 1) It would have been very useful to have explicit configure options > such as --with-gmp-lib=path and --with-gmp-include=path (etc) that > explicitly locate the *.a and *.h directories, rather than (or in > addition to) the existing "install directory" and "build directory" > options. Yes, the configure included in mpfr itself has this for searching for GMP which it relies on. I'll add something for this in GCC also. > 2) Ideally IMHO the top-level configure (or at least the libgfortran > configure) would test the execution of some or all of the required > functions in GMP/MPFR. I vaguely recall that this is possible with > autoconf, and should be more robust. Would it add too much complexity > to the top-level configure? > Thanks, > - Matt I tend to be reluctant about run tests because they don't work with a cross-compiler. Would you please tell me specifically what problem checking at runtime would prevent that the existing compile test doesn't detect? Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: build failure, GMP not available
> Thanks for the report. I believe some of your issues can be addressed. > I'll add what I can to my TODO list. However I don't know if anything > will be done for the 4.1.x series given the restriction for regression > fixes only. I guess it depends on your definition of "regression", these > problems have always existed since we started relying on gmp/mpfr in 4.0. > However the 3.4 series didn't need these libraries so it never had these > kind of problems building fortran. :-) I think previous consensus has been that "regressions" against g77 aren't really regressions for release purposes. We removed one language and added a new one, they just happen to both be called FORTRAN ;-) Paul
Re: building gcc4-4.3.0-20061104/11 failure on OSX 10.3
Thanks for the answers. > Please remove your changes from your tree, re-pull the current > mainline and try building again. See my posting test results posting > in http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00708.html for > details on how I got those results. You don't have to apply the > referenced patch, as I already checked it into mainline. I am not really maintaining a tree. Usually I download the weekly snapshot (due tomorrow) and do the buils through a modified Fink script. If I have a problem, I look if I can solve it by small changes in the script. If the problem comes from the snapshot itself, I cry for help and without answer I do what I did, i.e. try some patches, but I do my best to avoid that. Unless there is an emergency I do not foresee, I'll try with the 20061118 snapshot in which the patch should be included (I have seen it in CVS). > You can run as -v to see what version of cctools you have. Apple Computer, Inc. version cctools-590.36~obj, GNU assembler version 1.38 Note that I have also [karma] f90/bug% /sw/lib/odcctools-10.4/bin/ld -v Apple Computer, Inc. version odcctools-622.3od15 (copied from my 10.4 laptop) though I never used it under 10.3. The Fink script use several --with-xx to look at the tools (ld, as, nm, libtool, ...) in a separate directory. I have added a few more without solving the problem. It seems that the with-* mechanism is not fully implemented since there is a hardcoded /usr/bin/libtool in gcc/config/darwin.h and a default (from path) nm in libstdc++-v3/scripts/make_exports.pl. I don't know if there are other instances for other commands (I grepped 'strip' in the hierarchy, but had too many outputs to really use them). > Let me know if that works for you. I should have an answer by next Monday. > > Mike was considering simply declaring that GCC 4.3 won't work on > > Mac OS 10.3. > > No, not really. I'll declare that using things older than 10.3.9 are > gonna be hard, as the required cctools package was built for 10.3.9, > however, if one gets the sources for cctools and builds them on older > releases, one might be able to go back father. I don't think I care > enough to do that much work. I am under 10.3.9 and I think the requirement to have it + cctools-590.36 is reasonable. > > 10.3 is quite old now, and there will be very few users by the time > > that 4.3 is released. > > I tested it out on mainline and it works just fine (now). :-) I'ld prefer you wait until the 10.5 release, before declaring GCC 4.3 won't work on OSX 10.3. Thanks Dominique
alias slowdown?
I just tried compiling cplusplus_grammer.ii with mainline, checking disabled, and had to stop it after 30 minutes (use to be <50 seconds on my x86-linux box). A quick check with GDB seems to show that its spending in inordinate amount of time in may_alias: #0 0x0816d1ac in bitmap_ior_into (a=0x99916d8, b=0x98f60a0) at /src/gcc/2006-11-16/gcc/gcc/bitmap.c:1167 #1 0x083c8071 in set_union_with_increment (to=0x99916d8, from=0x98f60a0, inc=0) at /src/gcc/2006-11-16/gcc/gcc/tree-ssa-structalias.c:715 #2 0x083cacf4 in solve_graph (graph=0x9a11d10) at /src/gcc/2006-11-16/gcc/gcc/tree-ssa-structalias.c:1721 #3 0x083cbb7d in compute_points_to_sets (ai=0x8ccc200) at /src/gcc/2006-11-16/gcc/gcc/tree-ssa-structalias.c:4846 #4 0x08133ab9 in compute_may_aliases () at /src/gcc/2006-11-16/gcc/gcc/tree-ssa-alias.c:665 If anyone has changed this recently, you might want to have a look. Andrew
Re: build failure, GMP not available
>From: "Kaveh R. GHAZI" <[EMAIL PROTECTED]> >> Matt Fago wrote: >> One issue here is that '--with-mpfr=path' assumes that 'libmpfr.a' is >> in 'path/lib' (not true for how I installed it), while '--with-mpfr- >> dir=path' assumes that 'libmpfr.a' is in 'path', rather than >> 'path/.libs' (can this work for anyone?). Note that '--with-gmp- >> dir=path' does look in 'path/.libs'. > >This problem appears in the 4.0 series all the way through current >mainline. I do believe it should be fixed and it is simple to do so. I'll >take care of it. > >> My comments: >> >> 1) It would have been very useful to have explicit configure options >> such as --with-gmp-lib=path and --with-gmp-include=path (etc) that >> explicitly locate the *.a and *.h directories, rather than (or in >> addition to) the existing "install directory" and "build directory" >> options. > >Yes, the configure included in mpfr itself has this for searching for GMP >which it relies on. I'll add something for this in GCC also. Thank you. >> 2) Ideally IMHO the top-level configure (or at least the libgfortran >> configure) would test the execution of some or all of the required >> functions in GMP/MPFR. I vaguely recall that this is possible with >> autoconf, and should be more robust. Would it add too much complexity >> to the top-level configure? > >I tend to be reluctant about run tests because they don't work with a >cross-compiler. Would you please tell me specifically what problem >checking at runtime would prevent that the existing compile test doesn't >detect? Yes, a cross-compiler could not do runtime tests. I was trying to think of a more robust configuration-time test. This is difficult as I do not quite understand why configure was successful in finding the libraries with the correct versions, but yet the compilation itself failed. Would a link test against all of the required GMP/MPFR functions (via AC_CHECK_LIB etc) offer anything? Thanks, - Matt
Re: alias slowdown?
On Fri, 2006-11-17 at 12:22 -0500, Andrew MacLeod wrote: > I just tried compiling cplusplus_grammer.ii with mainline, checking > disabled, and had to stop it after 30 minutes (use to be <50 seconds on > my x86-linux box). A quick check with GDB seems to show that its > spending in inordinate amount of time in may_alias: > > #0 0x0816d1ac in bitmap_ior_into (a=0x99916d8, b=0x98f60a0) > at /src/gcc/2006-11-16/gcc/gcc/bitmap.c:1167 > #1 0x083c8071 in set_union_with_increment (to=0x99916d8, from=0x98f60a0, > inc=0) at /src/gcc/2006-11-16/gcc/gcc/tree-ssa-structalias.c:715 > #2 0x083cacf4 in solve_graph (graph=0x9a11d10) > at /src/gcc/2006-11-16/gcc/gcc/tree-ssa-structalias.c:1721 > #3 0x083cbb7d in compute_points_to_sets (ai=0x8ccc200) > at /src/gcc/2006-11-16/gcc/gcc/tree-ssa-structalias.c:4846 > #4 0x08133ab9 in compute_may_aliases () > at /src/gcc/2006-11-16/gcc/gcc/tree-ssa-alias.c:665 > > > If anyone has changed this recently, you might want to have a look. Im seeing the same thing in all.i from 26854... I had to kill the process after 20 minutes. It was in 'solve_graph' there as well. Andrew
gcc-4.1-20061117 is now available
Snapshot gcc-4.1-20061117 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20061117/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 118945 You'll find: gcc-4.1-20061117.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20061117.tar.bz2 C front end and core compiler gcc-ada-4.1-20061117.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20061117.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20061117.tar.bz2 C++ front end and runtime gcc-java-4.1-20061117.tar.bz2 Java front end and runtime gcc-objc-4.1-20061117.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20061117.tar.bz2The GCC testsuite Diffs from 4.1-20061110 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
AVR byte swap optimization
The following macro expands to some rather frightful code on the AVR:
#define BSWAP_16(x) \
x) >> 8) & 0xff) | (((x) & 0xff) << 8))
uint16_t bswap_16(uint16_t x)
{
0:9c 01 movwr18, r24
2:89 2f mov r24, r25
4:99 27 eor r25, r25
6:32 2f mov r19, r18
8:22 27 eor r18, r18
return BSWAP_16(x);
}
a:82 2b or r24, r18
c:93 2b or r25, r19
e:08 95 ret
Ideally, this macro would expand to three mov instructions and a ret.
Is there anything I can do to help GCC along here? I'm using GCC 4.1.0
with -O2.
I won't bother to show bswap_32 here, which produces a real disaster!
Think 47 instructions, for what should be 6.
Cheers,
Shaun
$ avr-gcc --version |head -1
avr-gcc (GCC) 4.1.0
bootstrapping r118945 failed
SVN revision: 118945 Host: i686-pc-linux-gnu /home/daniel/svn-build/gcc-head/./gcc/xgcc -B/home/daniel/svn-build/gcc-head/./g cc/ -B/home/daniel/i686-pc-linux-gnu/gcc-svn//i686-pc-linux-gnu/bin/ -B/home/dan iel/i686-pc-linux-gnu/gcc-svn//i686-pc-linux-gnu/lib/ -isystem /home/daniel/i686 -pc-linux-gnu/gcc-svn//i686-pc-linux-gnu/include -isystem /home/daniel/i686-pc-l inux-gnu/gcc-svn//i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/home/dani el/svn/gcc/libgfortran -I. -iquote/home/daniel/svn/gcc/libgfortran/io -I/home/da niel/svn/gcc/libgfortran/../gcc -I/home/daniel/svn/gcc/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prot otypes -Wold-style-definition -Wextra -Wwrite-strings -ftree-vectorize -funroll- loops -O2 -g -O2 -c /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c -fPI C -DPIC -o .libs/matmul_i4.o /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c: In function 'matmul_i4': /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c:337: error: verify_flow_i nfo: Block 136 has loop_father, but there are no loops /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c:337: error: verify_flow_info: Block 135 has loop_father, but there are no loops [snipped 133 identical messages] /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c:337: error: verify_flow_info: Block 2 has loop_father, but there are no loops /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c:337: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [matmul_i4.lo] Error 1 make[3]: Leaving directory `/home/daniel/svn-build/gcc-head/i686-pc-linux-gnu/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/daniel/svn-build/gcc-head/i686-pc-linux-gnu/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/home/daniel/svn-build/gcc-head'
RE: [avr-gcc-list] AVR byte swap optimization
You could always equate the macro to some inline assembly like what is done
for a number of avr-libc macros.
Eric Weddington
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Shaun Jackman
> Sent: Friday, November 17, 2006 4:31 PM
> To: avr-gcc-list@nongnu.org; gcc@gcc.gnu.org
> Subject: [avr-gcc-list] AVR byte swap optimization
>
> The following macro expands to some rather frightful code on the AVR:
>
> #define BSWAP_16(x) \
> x) >> 8) & 0xff) | (((x) & 0xff) << 8))
>
> uint16_t bswap_16(uint16_t x)
> {
>0: 9c 01 movwr18, r24
>2: 89 2f mov r24, r25
>4: 99 27 eor r25, r25
>6: 32 2f mov r19, r18
>8: 22 27 eor r18, r18
> return BSWAP_16(x);
> }
>a: 82 2b or r24, r18
>c: 93 2b or r25, r19
>e: 08 95 ret
>
> Ideally, this macro would expand to three mov instructions and a ret.
> Is there anything I can do to help GCC along here? I'm using GCC 4.1.0
> with -O2.
>
> I won't bother to show bswap_32 here, which produces a real disaster!
> Think 47 instructions, for what should be 6.
>
> Cheers,
> Shaun
>
> $ avr-gcc --version |head -1
> avr-gcc (GCC) 4.1.0
>
>
> ___
> AVR-GCC-list mailing list
> AVR-GCC-list@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>
Re: bootstrapping r118945 failed
Reported (and confirmed) here: http://gcc.gnu.org/bugzilla//show_bug.cgi?id=29879 > SVN revision: 118945 > Host: i686-pc-linux-gnu > > /home/daniel/svn-build/gcc-head/./gcc/xgcc > -B/home/daniel/svn-build/gcc-head/./g > cc/ -B/home/daniel/i686-pc-linux-gnu/gcc-svn//i686-pc-linux-gnu/bin/ > -B/home/dan > iel/i686-pc-linux-gnu/gcc-svn//i686-pc-linux-gnu/lib/ -isystem > /home/daniel/i686 > -pc-linux-gnu/gcc-svn//i686-pc-linux-gnu/include -isystem > /home/daniel/i686-pc-l > inux-gnu/gcc-svn//i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. > -I/home/dani > el/svn/gcc/libgfortran -I. -iquote/home/daniel/svn/gcc/libgfortran/io > -I/home/da > niel/svn/gcc/libgfortran/../gcc > -I/home/daniel/svn/gcc/libgfortran/../gcc/config > -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes > -Wmissing-prot > otypes -Wold-style-definition -Wextra -Wwrite-strings -ftree-vectorize > -funroll- > loops -O2 -g -O2 -c /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c > -fPI > C -DPIC -o .libs/matmul_i4.o > /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c: In > function 'matmul_i4': > /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c:337: error: > verify_flow_i > nfo: Block 136 has loop_father, but there are no loops > /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c:337: error: > verify_flow_info: Block 135 has loop_father, but there are no loops > > [snipped 133 identical messages] > > /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c:337: error: > verify_flow_info: Block 2 has loop_father, but there are no loops > /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c:337: internal compiler > error: verify_flow_info failed > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > make[3]: *** [matmul_i4.lo] Error 1 > make[3]: Leaving directory > `/home/daniel/svn-build/gcc-head/i686-pc-linux-gnu/libgfortran' > make[2]: *** [all] Error 2 > make[2]: Leaving directory > `/home/daniel/svn-build/gcc-head/i686-pc-linux-gnu/libgfortran' > make[1]: *** [all-target-libgfortran] Error 2 > make[1]: Leaving directory `/home/daniel/svn-build/gcc-head'
Re: alias slowdown?
On 11/17/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote: On Fri, 2006-11-17 at 12:22 -0500, Andrew MacLeod wrote: > I just tried compiling cplusplus_grammer.ii with mainline, checking > disabled, and had to stop it after 30 minutes (use to be <50 seconds on > my x86-linux box). A quick check with GDB seems to show that its > spending in inordinate amount of time in may_alias: We used to basically say all of these cases pointed to everything and anything, and collapse them very quickly. Now we compute a correct set of aliases and escaped variables It takes a while in huge cases like this. I'm working on fixing it.
