Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0
On Dec 16, 2005, at 8:25 PM, Eric Christopher wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082 Unfortunately, even with my Apple Developer account I can't seem to figure out how to look up radar reports that I haven't submitted. I took a look at the radar. Says, effectively, that the bug has been fixed in ld64 and will be in the next release. Great! Thanks. Brad
Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082 Unfortunately, even with my Apple Developer account I can't seem to figure out how to look up radar reports that I haven't submitted. I took a look at the radar. Says, effectively, that the bug has been fixed in ld64 and will be in the next release. -eric
Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0
On Dec 16, 2005, at 6:23 PM, Mike Stump wrote: On Jun 20, 2005, at 2:41 PM, Bradley Lucier wrote: I can't seem to build any 64-bit shared library on powerpc-apple- darwin8.1.0, although I can now run the test suite more effectively; see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110 and http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01124.html So, I thought I'd ping you and see if everything is nearer to normal now. Thanks! Unfortunately not. Geoff thinks that not being able to build a 64-bit shared library is a libtool problem; the discussion seems to have ended in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082 Unfortunately, even with my Apple Developer account I can't seem to figure out how to look up radar reports that I haven't submitted. And there seem to be a large number of 64-bit failures in the 4.1 test suite; the results from the 10th can be found at http://www.math.purdue.edu/~lucier/gcc/test-results/4_1-12-10-2005.gz About my earlier e-mail regarding the test results on the 6th: http://gcc.gnu.org/ml/gcc/2005-12/msg00182.html Geoff commented: http://gcc.gnu.org/ml/java/2005-12/msg00093.html Brad
Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0
On Jun 20, 2005, at 2:41 PM, Bradley Lucier wrote: I can't seem to build any 64-bit shared library on powerpc-apple- darwin8.1.0, although I can now run the test suite more effectively; see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110 and http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01124.html So, I thought I'd ping you and see if everything is nearer to normal now.
Re: How to rebuild stage 1?
A wiki page that has the mapping from the old style to the new style targets is appropriate. I know that I'll hit the, what is x called now, and I too will be at a loss. Going back and reading the email archives to find it would be annoying. Strongly agreed, though once it gets finalized it should be moved from the wiki into the main GCC documentation. Even better though would be some option to keep the "old style". As I understand it, the point here is to add functionality at top level, but that shouldn't be at the expense of functionality at the gcc/ level. Indeed I see no reason that we can't be upwards compatible. It's extremely valuable to have a single script that can do a build given any GCC version and the fewer the number of parameterizations that are needed in that script the better. Also, it's important to keep in mind that many people have multiple build directories for many versions of the compiler (3.2, 3.4, 4.0, 4.1, head) and many targets so uniformity is key to managing that complexity.
Re: http://gcc.gnu.org/onlinedocs/gcc/ is 403
On Dec 16, 2005, at 3:05 PM, Richard Guenther wrote: $subject - since a day now. Thanks, fixed.
http://gcc.gnu.org/onlinedocs/gcc/ is 403
$subject - since a day now. Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
Build success for gcc 3.4.5 on alphaev68-dec-osf5.1 (CompaqTru64UNIX)
Cool !! HP-Compaq ES45 Successful build of 3.4.5 for alphaev68-dec-osf5.1 (c,c++,f77,objc,ada). [EMAIL PROTECTED]:~/GNU/gcc-3.4.5#gcc -v Using built-in specs. Configured with: ./configure --host=alphaev68-dec-osf5.1 --prefix=/usr/local --enable-languages=c,c++,f77,objc,ada --enable-version-specific-runtime-libs --enable-shared --enable-libgcj --with-gc=simple --enable-nls --enable-interpreter Thread model: posix gcc version 3.4.5 Sincerely, Stefano Curtarolo -- Prof. Stefano Curtarolo Assistant Professor of Materials Science Duke University, Dept. Mechanical Engineering and Materials Science 144 Hudson Hall, Box 90300, Durham, NC 27708-0300 phone 919-660-5506 [EMAIL PROTECTED] http://alpha.mems.duke.edu --
gcc-4.1-20051216 is now available
Snapshot gcc-4.1-20051216 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20051216/ 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 108690 You'll find: gcc-4.1-20051216.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20051216.tar.bz2 C front end and core compiler gcc-ada-4.1-20051216.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20051216.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20051216.tar.bz2 C++ front end and runtime gcc-java-4.1-20051216.tar.bz2 Java front end and runtime gcc-objc-4.1-20051216.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20051216.tar.bz2The GCC testsuite Diffs from 4.1-20051209 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.
Re: 8 Dec 05 notes from GCC improvement for Itanium conference call
On Fri, 2005-12-16 at 12:01 -0800, Chris Lattner wrote: > On Dec 16, 2005, at 11:47 AM, Daniel Berlin wrote: > > > On Fri, 2005-12-16 at 11:27 -0800, Chris Lattner wrote: > >> On Dec 16, 2005, at 11:15 AM, Mark K. Smith wrote: > >>> Additionally to the obstacles to adopt LLVM mentioned by Diego, I > >>> named usage of C++ (although it has advantages too) and patents. > >>> LLVM > >>> should be checked for usage of compiler patents. Gcc people avoided > >>> many patents especially from Microsoft. We can not be sure right now > >>> about LLVM. > >> > >> The confusion is basically centered around the distinction between my > >> PhD research work and LLVM itself. > >> The thesis work I did at UIUC does relate closely to Steensgaard's > >> pointer analysis work, which is patented by Microsoft. However, this > >> thesis work is not currently used by LLVM, and certainly won't be > >> incorporated directly into GCC (for obvious patent reasons), so this > >> isn't an issue with LLVM adoption by GCC. > > > However, I am certainly not a lawyer and defer to those who are :). > If people would be more comfortable with the code out of the *llvm* > distro, I can remove it, just let me know. In any case, this issue > still has nothing to do with GCC integration. I agree completely on that point. I don't think we need to be worrying about the codebase of LLVM in terms of patents and copyright at this point. I've scanned it and certainly DSAA and the Steensgaard implementation were the only thing that popped out at me as being something to worry about later. LLVM has more or less avoided the same patents GCC has. --Dan
Re: 8 Dec 05 notes from GCC improvement for Itanium conference call
On Dec 16, 2005, at 11:47 AM, Daniel Berlin wrote: On Fri, 2005-12-16 at 11:27 -0800, Chris Lattner wrote: On Dec 16, 2005, at 11:15 AM, Mark K. Smith wrote: Additionally to the obstacles to adopt LLVM mentioned by Diego, I named usage of C++ (although it has advantages too) and patents. LLVM should be checked for usage of compiler patents. Gcc people avoided many patents especially from Microsoft. We can not be sure right now about LLVM. The confusion is basically centered around the distinction between my PhD research work and LLVM itself. The thesis work I did at UIUC does relate closely to Steensgaard's pointer analysis work, which is patented by Microsoft. However, this thesis work is not currently used by LLVM, and certainly won't be incorporated directly into GCC (for obvious patent reasons), so this isn't an issue with LLVM adoption by GCC. The sad fact is it probably doesn't matter if it's actually run by default or not. It is built into the binary, exists in the source tree, and *can be run* by simply passing a command line option to opt. That's the thing. opt isn't part of the C/C++ compiler. This stuff isn't built into the binary, and cannot be run by passing an option to the C compiler. It does exist in the (LLVM) source tree, but if that's an issue, it can be remedied. This invariably counts as a "making of the patented invention", and is considered infringement, even if it's not run by default. If you made it not built into the binary, you would be on more solid legal ground (but even then they'd still sue you anyway :P). It's not built into the binary. Again, 'opt' is a developer tool and not part of the C/C++ front-end (the front-end never invokes opt, etc). However, I am certainly not a lawyer and defer to those who are :). If people would be more comfortable with the code out of the *llvm* distro, I can remove it, just let me know. In any case, this issue still has nothing to do with GCC integration. -Chris
Re: 8 Dec 05 notes from GCC improvement for Itanium conference call
On Fri, 2005-12-16 at 11:27 -0800, Chris Lattner wrote: > On Dec 16, 2005, at 11:15 AM, Mark K. Smith wrote: > > Additionally to the obstacles to adopt LLVM mentioned by Diego, I > > named usage of C++ (although it has advantages too) and patents. LLVM > > should be checked for usage of compiler patents. Gcc people avoided > > many patents especially from Microsoft. We can not be sure right now > > about LLVM. > > Hi, > > For what it's worth, LLVM doesn't depend on any technology patented > by Microsoft that I'm aware of. This seems to be an item of common > confusion, so I'll clear it up here. > > The confusion is basically centered around the distinction between my > PhD research work and LLVM itself. > The thesis work I did at UIUC does relate closely to Steensgaard's > pointer analysis work, which is patented by Microsoft. However, this > thesis work is not currently used by LLVM, and certainly won't be > incorporated directly into GCC (for obvious patent reasons), so this > isn't an issue with LLVM adoption by GCC. The sad fact is it probably doesn't matter if it's actually run by default or not. It is built into the binary, exists in the source tree, and *can be run* by simply passing a command line option to opt. This invariably counts as a "making of the patented invention", and is considered infringement, even if it's not run by default. If you made it not built into the binary, you would be on more solid legal ground (but even then they'd still sue you anyway :P). --Dan
Re: Performance comparison of gcc releases
Hi, Am Freitag, 16. Dezember 2005 19:31 schrieb Dan Kegel: > Your PR is a bit short on details. For instance, it'd be nice to > include a link to the source for nbench, so people don't have > to guess what version you're using. Was it > http://www.tux.org/~mayer/linux/nbench-byte-2.2.2.tar.gz > ? > > It'd be even more helpful if you included a recipe a sleepy person > could use to reproduce the problem. In this case, > something like > > wget http://www.tux.org/~mayer/linux/nbench-byte-2.2.2.tar.gz > tar -xzvf nbench-byte-2.2.2.tar.gz > cd nbench-byte-2.2.2 > make CC=gcc-4.0.1 CFLAGS="-ftree-loop-linear" > > Unfortunately, I couldn't reproduce your problem with that command. > Can you give me any tips? > > Finally, it's helpful when replying to the list about filing a PR > to include the PR number or a link to the PR. > The shortest link is just gcc.gnu.org/PR%d, e.g. >http://gcc.gnu.org/PR25449 Sorry, i had forgotten to give the information. It was nbench-2.2.2. a 'make CC=gcc-4.0.2 CFLAGS="-O3 -march=... -ftree-loop-linear"' should be enough. The bugreport is a duplicate of 20256, as i have written into bugzilla. The source extracted in 20256 is nearly the same as the 'neural net' benchmark. The next time i write a bugreport, i should more concentrate on it, sorry again for this. cu, Ronny Peine
Re: 8 Dec 05 notes from GCC improvement for Itanium conference call
On Dec 16, 2005, at 11:15 AM, Mark K. Smith wrote: Additionally to the obstacles to adopt LLVM mentioned by Diego, I named usage of C++ (although it has advantages too) and patents. LLVM should be checked for usage of compiler patents. Gcc people avoided many patents especially from Microsoft. We can not be sure right now about LLVM. Hi, For what it's worth, LLVM doesn't depend on any technology patented by Microsoft that I'm aware of. This seems to be an item of common confusion, so I'll clear it up here. The confusion is basically centered around the distinction between my PhD research work and LLVM itself. The thesis work I did at UIUC does relate closely to Steensgaard's pointer analysis work, which is patented by Microsoft. However, this thesis work is not currently used by LLVM, and certainly won't be incorporated directly into GCC (for obvious patent reasons), so this isn't an issue with LLVM adoption by GCC. If you or the Gelato group has any questions about LLVM, I'd be more than happy to answer them either on this list or over the phone. -Chris
8 Dec 05 notes from GCC improvement for Itanium conference call
ON THE CALL: Shin-ming Liu (HP), Vladimir Makarov (Red Hat), Diego Novillo (Red Hat), Mark Smith (Gelato), Bob Kidd (UIUC), Mark Davis (Intel) A fair amount of time was spent discussing the pros and cons of LLVM vs. LTO. Keep in mind that the next Gelato conference is coming up in April 06. If you would like to speak in the GCC track, please contact Mark Smith. Comments from each participant on the call can be found below. NEXT MEETING: January 12th, 2006. Details will be emailed out prior to the call. Bob Kidd: - The ia64-improvements branch is up. I haven't had time to do much with it, but I've checked it out and bootstrapped. I applied Steven Bosscher's revised superblock patch, bootstrapped and tested it. I'm looking at updating the branch to either 4.2 or CVS head and will check in the superblock patch. Shin-ming Liu: -- * HP has posted the GCC 4.0.2 source and binary package on HP site for HP-UX in November * HP is working toward the similar posting for Linux in the near future * HP is actively participating in the LTO activity in GCC community * HP has started the alternative backend effort based on Open64 with several universities Vladimir Makarov: - I asked Bob to tell more details about superblock scheduling he made. Because the current version does not take predication into account, I told that to get better results it is good to combine predication and superblock forming in future. Also superblock scheduling could work without profile information as it does currently according to Bob's review. Gcc has decent evaluation of branch probabilities. It would be reasonable to try how superblock scheduling will work with the branch probabilities evaluation. As for work status of ISP RAS team, they work on infrastructure for another insn scheduling. It is a big project. They sent patch for improvement of aliasing analysis for ia64. Diego Novillo and Daniel Berlin are reviewing the patch. They'll send patch for speculation support for review soon. It is control and data speculation support with recovering code. Now it is necessary only for ia64 but it will be useful for future Intel x86 and x86_64 processors which as I heard will have speculation support too. As for LLVM, I told it is a very interesting research project. In any case it will help to gcc finally and itself. We will see will it be finally adopted in gcc. At least, it have more chances for that than OpenRC with its WHIRL because transition of copyrights to FSF of LLVM is more probable than one of OpenRC from SGI. But adoption of LLVM should not stop other project therefore LTO is a right thing to do. The competition is good and there will be more chance to have intermodule optimizations finally. Additionally to the obstacles to adopt LLVM mentioned by Diego, I named usage of C++ (although it has advantages too) and patents. LLVM should be checked for usage of compiler patents. Gcc people avoided many patents especially from Microsoft. We can not be sure right now about LLVM. Diego Novillo: -- I talked about the new developments in GCC for doing link-time optimizations. We discussed both the LTO proposal and LLVM. Although it's not clear at the moment which proposal will end up being adopted, we all agreed this is an excellent sign that GCC will start evolving in that direction. I also talked about the new ia64-improvements branch and Dmitry's alias patch. The ia64-improvements branch is ready for people to use. I have started reviewing Dmitry's patch and will try to send feedback in the next few days. Mark Smith: --- I will continue to work with Intel to secure a Montecito SDV to use for GCC builds. Itanium Solutions Alliance has funded Bob Kidd's GCC superblock work. I also talked about the upcoming Gelato conference in April 2006. We want to have a strong GCC track at the meeting. Please consider attending. Shin-ming and I will work together on designing the track. If you would like to speak, please contact one of us.
Re: How to rebuild stage 1?
On Dec 16, 2005, at 6:23 AM, Daniel Berlin wrote: A simple summary would be very helpful in trying to figure out what i want to do now. I'm sure most of the functionality exists, i'm just not sure what it's called anymore :) A wiki page that has the mapping from the old style to the new style targets is appropriate. I know that I'll hit the, what is x called now, and I too will be at a loss. Going back and reading the email archives to find it would be annoying.
Re: Performance comparison of gcc releases
On Dec 16, 2005, at 10:31 AM, Dan Kegel wrote: Ronny Peine wrote: -ftree-loop-linear is removed from the testingflags in gcc-4.0.2 because it leads to an endless loop in neural net in nbench. Could you fill a bug report for this one? Done. This is probably the same as 20256. Your PR is a bit short on details. For instance, it'd be nice to include a link to the source for nbench, so people don't have to guess what version you're using. Was it http://www.tux.org/~mayer/linux/nbench-byte-2.2.2.tar.gz ? It'd be even more helpful if you included a recipe a sleepy person could use to reproduce the problem. In this case, something like wget http://www.tux.org/~mayer/linux/nbench-byte-2.2.2.tar.gz tar -xzvf nbench-byte-2.2.2.tar.gz cd nbench-byte-2.2.2 make CC=gcc-4.0.1 CFLAGS="-ftree-loop-linear" Unfortunately, I couldn't reproduce your problem with that command. Can you give me any tips? Finally, it's helpful when replying to the list about filing a PR to include the PR number or a link to the PR. The shortest link is just gcc.gnu.org/PR%d, e.g. http://gcc.gnu.org/PR25449 - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
RE: Supporting multiple instructions sets within a single machine description
Hi! I have plan to make it in near future, if u can help me, ideas or coding, please se on next thread: http://gcc.gnu.org/ml/gcc-patches/2005-12/threads.html#01005 Subj: Some patches for ARM-GCC From: Richard Earnshaw To: tm_gccmail at mail dot kloo dot net Cc: Jon Beniston , gcc at gcc dot gnu dot org, Richard dot Earnshaw at arm dot com Date: Thu, 13 Mar 2003 09:45:08 + Subject: Re: Supporting multiple instructions sets within a single machine description Organization: ARM Ltd. Reply-to: Richard dot Earnshaw at arm dot com On Wed, 12 Mar 2003, Jon Beniston wrote: > > I was wondering what support there is within GCC for supporting multiple > instruction sets within a single machine description. E.g. ARM & Thumb or MIPS32/MIPS16. This is already done. USTL! Don't you mean UTSL! > Is it possible for GCC to compile to different > instructions sets at a finer granularity than a single compilation unit? > i.e. Can I get GCC to compile one function in Thumb and another using > the full ARM instruction set. No. It's set using command-line options. At present. I'd like to see an attribute that could change compilation of individual functions... but it's not easy, given the current structure of the compiler. -- Regards, Ivan
re: Performance comparison of gcc releases
Ronny Peine wrote: >> > -ftree-loop-linear is removed from the testingflags in gcc-4.0.2 because >> > it leads to an endless loop in neural net in nbench. >> >> Could you fill a bug report for this one? > >Done. Your PR is a bit short on details. For instance, it'd be nice to include a link to the source for nbench, so people don't have to guess what version you're using. Was it http://www.tux.org/~mayer/linux/nbench-byte-2.2.2.tar.gz ? It'd be even more helpful if you included a recipe a sleepy person could use to reproduce the problem. In this case, something like wget http://www.tux.org/~mayer/linux/nbench-byte-2.2.2.tar.gz tar -xzvf nbench-byte-2.2.2.tar.gz cd nbench-byte-2.2.2 make CC=gcc-4.0.1 CFLAGS="-ftree-loop-linear" Unfortunately, I couldn't reproduce your problem with that command. Can you give me any tips? Finally, it's helpful when replying to the list about filing a PR to include the PR number or a link to the PR. The shortest link is just gcc.gnu.org/PR%d, e.g. http://gcc.gnu.org/PR25449 - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
RE: creating a new branch webpage
[EMAIL PROTECTED] wrote: > Dear all, > I'm opening a new branch and would like to request some assistance > updating the online material. Specifically, how do I add the branch > information to http://gcc.gnu.org/svn.html#devbranches. Also, would it be > possible to create an associated project page (e.g., > http://gcc.gnu.org/projects/tree-profiling.html)? The website is stored in the old gcc cvs repository; checkout the toplevel module 'wwwdocs' to get it. Then you can just do the edits yourself and submit a patch to [EMAIL PROTECTED], same as any other patch. cheers, DaveK -- Can't think of a witty .sigline today
creating a new branch webpage
Dear all, I'm opening a new branch and would like to request some assistance updating the online material. Specifically, how do I add the branch information to http://gcc.gnu.org/svn.html#devbranches. Also, would it be possible to create an associated project page (e.g., http://gcc.gnu.org/projects/tree-profiling.html)? Thanks, Chad Rosier
Re: Performance comparison of gcc releases
Hi, Am Freitag, 16. Dezember 2005 19:50 schrieb Sebastian Pop: > Ronny Peine wrote: > > -ftree-loop-linear is removed from the testingflags in gcc-4.0.2 because > > it leads to an endless loop in neural net in nbench. > > Could you fill a bug report for this one? Done. cu, Ronny Peine
Re: Add revision number to gcc version?
On Fri, Dec 16, 2005 at 12:07:54PM +0100, Volker Reichelt wrote: > > 1. contrib/gcc_update creates gcc/REVISION with branch name and > > revision number. > > 2. If gcc/REVISION exists, it will be used in gcc/version.c. > > > > With those 2 patches, I got > > > > [EMAIL PROTECTED] gcc]$ ./xgcc --version > > xgcc (GCC) 4.1.0 (gcc-4_1-branch revision 108596) 20051215 (prerelease) > > [snip] > > > xgcc (GCC) 4.2.0 (trunk revision 108596) 20051215 (experimental) > > IMHO we should change the current naming system as little as possible > for those who run scripts to extract the information from the compiler > automatically. (Maybe I'm the only one, but I do.) > > Therefore I'd like to suggest to add the new stuff at the end and > with brackets instead of parentheses to make that information easily > extractable as well. > > xgcc (GCC) 4.1.0 20051215 (prerelease) [gcc-4_1-branch revision 108596] > xgcc (GCC) 4.2.0 20051215 (experimental) [trunk revision 108596] > > Somebody on this thread also suggested to skip the date and only use > the revision number. I don't think that this is a good idea, because > > 1.) there are scripts out there that rely on the date > (OK, maybe I'm the only one) > 2.) if we ever change the revision control system again, > these numbers are probably obsolete > 3.) the date carries a lot of information for humans (oh, this snapshot > is already two month old, I should get a new one) without having > to consult a database (for those who only download snapshots). > And this info is available offline, too. > Here are the new patches. I got [EMAIL PROTECTED] gcc-4.1]$ ./build-i686-linux/gcc/stage1/xgcc --version xgcc (GCC) 4.1.0 20051216 (prerelease) [gcc-4_1-branch revision 108649 clean] Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. H.J. 2005-12-16 H.J. Lu <[EMAIL PROTECTED]> * gcc_update: Create gcc/REVISION with branch name and revision number. Index: contrib/gcc_update === --- contrib/gcc_update (revision 108649) +++ contrib/gcc_update (working copy) @@ -250,8 +250,25 @@ exit 1 fi +rm -f info.$$ LAST_UPDATED gcc/REVISION + +svn info > info.$$ +revision=`grep Revision: info.$$ | awk '{ print $2 }'` +branch=`grep URL: info.$$ | sed -e "s,.*/,,g"` { date - echo "`TZ=UTC date` (revision `svnversion .`)" + echo "`TZ=UTC date` (revision $revision)" } > LAST_UPDATED + +rm -f info.$$ + +changed=`svn status | grep "^[ACDGMRX\!\~]" | grep -v " contrib/"` +if [ -n "$changed" ]; then + changed="modified" +else + changed="clean" +fi + +echo "[$branch revision $revision $changed]" > gcc/REVISION + touch_files_reexec 2005-12-16 H.J. Lu <[EMAIL PROTECTED]> * Makefile.in (REVISION): New. (REVISION_c): New. (REVISION_s): New. (version.o): Also depend on $(REVISION). Add -DREVISION=$(REVISION_s). * version.c (version_string): Add REVISION. --- gcc/Makefile.in.rev 2005-12-04 07:17:09.0 -0800 +++ gcc/Makefile.in 2005-12-16 07:49:52.0 -0800 @@ -703,11 +703,18 @@ TM_H = $(GTM_H) insn-constants.h in BASEVER := $(srcdir)/BASE-VER # 4.x.y DEVPHASE:= $(srcdir)/DEV-PHASE # experimental, prerelease, "" DATESTAMP := $(srcdir)/DATESTAMP # MMDD or empty +REVISION:= $(srcdir)/REVISION # [BRANCH revision XX] BASEVER_c := $(shell cat $(BASEVER)) DEVPHASE_c := $(shell cat $(DEVPHASE)) DATESTAMP_c := $(shell cat $(DATESTAMP)) +ifeq (,$(wildcard $(REVISION))) +REVISION:= +else +REVISION_c := $(shell cat $(REVISION)) +endif + version := $(BASEVER_c) # For use in version.c - double quoted strings, with appropriate @@ -719,6 +726,12 @@ BASEVER_s := "\"$(BASEVER_c)\"" DEVPHASE_s := "\"$(if $(DEVPHASE_c), ($(DEVPHASE_c)))\"" DATESTAMP_s := "\"$(if $(DEVPHASE_c), $(DATESTAMP_c))\"" +ifdef REVISION_c +REVISION_s := "\"$(if $(DEVPHASE_c), $(REVISION_c))\"" +else +REVISION_s := +endif + # Shorthand variables for dependency lists. TARGET_H = $(TM_H) target.h insn-modes.h MACHMODE_H = machmode.h mode-classes.def insn-modes.h @@ -1681,9 +1694,10 @@ options.o: options.c $(CONFIG_H) $(SYSTE dumpvers: dumpvers.c -version.o: version.c version.h $(DATESTAMP) $(BASEVER) $(DEVPHASE) +version.o: version.c version.h $(REVISION) $(DATESTAMP) $(BASEVER) $(DEVPHASE) $(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) \ -DBASEVER=$(BASEVER_s) -DDATESTAMP
Re: Performance comparison of gcc releases
Ronny Peine wrote: > > -ftree-loop-linear is removed from the testingflags in gcc-4.0.2 because it > leads to an endless loop in neural net in nbench. Could you fill a bug report for this one? Thanks, Sebastian
Re: Add revision number to gcc version?
On Thu, Dec 15, 2005 at 06:35:29PM -0500, Daniel Jacobowitz wrote: > On Thu, Dec 15, 2005 at 03:00:10PM -0800, David Daney wrote: > > I like this, but what if you also did an svn status to see if there were > > any modifications WRT the branch/revision and then add either 'clean' or > > 'modified' to the information. > > > > So you would get (gcc-4_1-branch revision 108596 modified) or > > (gcc-4_1-branch revision 108596 clean) > > I think we already had this discussion and decided that svn status took > too long in many cases. I think running "svn status" in ./configure may slow down configure a lot. Also, you may not always be able to run "svn status" in ./configure since a gcc tree may not be checked out with svn. However, running "svn status" in ./contrib/gcc_update may not be that noticeable. H.J.
Re: How to rebuild stage 1?
I normally work in the "gcc" object directory and keep files there built by the system compiler. That's my starting point. Then I do a "make" to build, "make bootstrap" to do a bootstrap, "make gnatlib_and_tools" and "make check-ada" to run acats, and then "make unstage1" to get back where I started from. If I want to run a full build and test, I go up to the top level directory and "make" and then "make check". In your case, I would probably use two build directories, one bootstrapped and one not. mkdir build cd build ../configure --enable-languages=all --disable-bootstrap make cd .. mkdir build-boot cd build-boot ../configure --enable-languages=all make make check-ada If you want to build only stage1 in the bootstrapped tree, you can use "make all-stage1". It will fail if you're in the non-bootstrapped tree. Note that all makes are invoked from the toplevel directory. Of course, you can still do "make" from the gcc directory, but it's not clear that you really want to do that (especially with the toplevel libgcc bits that are to come). A debugging session would be like (toplevel bootstrap on the left, old on the right): mkdir build-boot mkdir build cd build-boot cd build ../configure ../configure make make bootstrap (something fails in stage2, and I need to figure out a cc1 invocation command line. To do so, I usually cut and paste the xgcc options into a command line with -### added to it.) cd gcc cd gcc ./xgcc -### foobar ./xgcc -### foobar make all-stage1make restage1 cd gcc; gdb --args whatevergdb --args whatever From gdb, I would use "make cc1" as usual to rebuild. Can somebody summarize the targets (and directories) equivalent to the above in the new scheme? Maybe we could make a table of use cases like the above, and put it on the wiki. I can fill in the "toplevel bootstrap" case. Until then, remember that if you're having serious problems (like David Edelsohn has) you can use --disable-bootstrap. Paolo
[PATCH] BOOT_CFLAGS vs profiled_bootstrap on the mainline
Andrew Pinski wrote: Trying to see if a bug was fixed (and an approved patch by me was still needed), I noticed that BOOT_CFLAGS was being ignored for profiled_bootstrap. BOOT_CFLAGS was being ignored, period. :-) Can you try this (and maybe commit it as obvious)? Index: Makefile.def === --- Makefile.def(revision 108650) +++ Makefile.def(working copy) @@ -207,4 +207,5 @@ flags_to_pass = { flag= YACC ; }; // Host tools flags_to_pass = { flag= AR_FLAGS ; }; +flags_to_pass = { flag= BOOT_CFLAGS ; }; flags_to_pass = { flag= CFLAGS ; }; flags_to_pass = { flag= CXXFLAGS ; }; Paolo
Re: Adding an instruction to gcc (pass through)
Errr, you need to change the assembler to do this . GCC does not care about what sits inside __asm__ . cheers Ramana On Fri, 2005-12-16 at 09:18 -0500, Burt Walsh wrote: > > > I am using SimpleScalar (ARM ISA) to do some simulations. I have > added an > instruction to the SimpleScalar machine defintion. I would like to > use an > asm("newinst"::) to force my instruction to be placed into the object > file. It is saying bad instruction when I do this. Do I have to go > into > gcc and edit the arm.md or is there another way to get this > instruction to > take.
Re: How to rebuild stage 1?
I'm sure most of the functionality exists, i'm just not sure what it's called anymore :) I've lost track too. I haven't tried to do builds in the last few days, so I haven't seen what's there now, but my needs are simple: I normally work in the "gcc" object directory and keep files there built by the system compiler. That's my starting point. Then I do a "make" to build, "make bootstrap" to do a bootstrap, "make gnatlib_and_tools" and "make check-ada" to run acats, and then "make unstage1" to get back where I started from. If I want to run a full build and test, I go up to the top level directory and "make" and then "make check". Can somebody summarize the targets (and directories) equivalent to the above in the new scheme? It would also be good if somebody could give the recommended procedure to have a common script to build all the GCC versions.
Re: How to rebuild stage 1?
On Fri, 2005-12-16 at 08:45 -0500, Daniel Jacobowitz wrote: > On Fri, Dec 16, 2005 at 09:35:22AM +0100, Paolo Bonzini wrote: > > H. J. Lu wrote: > > >How can I rebuild stage 1 compiler with the system compiler? I used > > >to be able to do > > > > > ># cd gcc > > ># make unstage1 > > ># make restage1 > > > > > >But now ./prev-gcc/xgcc is used to build stage 1 compiler, not the > > >system compiler. > > > > If the old bootstrap mechanism had already been garbage collected, you > > would not have succeeded in doing "make unstage1" or "make restage1". > > > > What you want is, from the *toplevel* directory, "make all-stage1". I > > can rename it to "make restage1" if people care enough, but I think the > > new name fits more the toplevel Makefile's naming of targets (where you > > have all-host, all-target, etc.). > > What we really need is more documentation in the top-level Makefile > about the available targets and what they do, I think. A simple summary would be very helpful in trying to figure out what i want to do now. I'm sure most of the functionality exists, i'm just not sure what it's called anymore :) >
Adding an instruction to gcc (pass through)
Hi, I am using SimpleScalar (ARM ISA) to do some simulations. I have added an instruction to the SimpleScalar machine defintion. I would like to use an asm("newinst"::) to force my instruction to be placed into the object file. It is saying bad instruction when I do this. Do I have to go into gcc and edit the arm.md or is there another way to get this instruction to take. thanks,
Re: make install is broken on powerpc-darwin starting with a 3.3 compiler
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: | On Fri, Dec 16, 2005 at 10:05:06AM +0100, Paolo Bonzini wrote: | > Andrew Pinski wrote: | > | > >doing the following | > >$(srcdir)/configure --prefix=${HOME}/libobjc.trunk | > >--enable-languages=c,objc | > >make all | > >make -k check | > >make install | > | > Why is it recompiling libcpp? That's the real bug. | > | > Please open a PR because the discussion really belongs in Bugzilla. | | Whyever something is being recompiled, relying on it not to be is too | fragile; the libcpp Makefile has install: all, so make is going to go | and recheck everything anyway. It uses automake dependency generation | so maybe it's the headers in the gcc directory, or something like that. | | The real question in my mind is why it's using the system compiler. still it is a bit surprising to me that each time I say "make install", libcpp is recompiled. It seems to be the only GCC component behaving that way... -- Gaby
Re: make install is broken on powerpc-darwin starting with a 3.3 compiler
Paolo Bonzini <[EMAIL PROTECTED]> writes: | Andrew Pinski wrote: | | > doing the following | > $(srcdir)/configure --prefix=${HOME}/libobjc.trunk | > --enable-languages=c,objc | > make all | > make -k check | > make install | | Why is it recompiling libcpp? That's the real bug. I observed that each time I say "make install", libcpp is recompiled -- I usually build C++. -- Gaby
remaining phases of dfp-branch merge
I am now about half-way through the various phases I proposed for merging the dfp-branch into mainline. The patch I committed today was quite big, so in light of David Edelsohn's note tonight, I will sit back for a bit before dealing with the next chunk. Here is what remains: * Merge in middle-end changes. * Merge in i?86 and powerpc64 backend changes. * Merge in the changes (incl. configury) to the runtime library. * Merge in the testsuite. These phases are a bit smaller than the ones before them. They will be less invasive and quicker to review. Ben
Re: make install is broken on powerpc-darwin starting with a 3.3 compiler
On Fri, Dec 16, 2005 at 10:05:06AM +0100, Paolo Bonzini wrote: > Andrew Pinski wrote: > > >doing the following > >$(srcdir)/configure --prefix=${HOME}/libobjc.trunk > >--enable-languages=c,objc > >make all > >make -k check > >make install > > Why is it recompiling libcpp? That's the real bug. > > Please open a PR because the discussion really belongs in Bugzilla. Whyever something is being recompiled, relying on it not to be is too fragile; the libcpp Makefile has install: all, so make is going to go and recheck everything anyway. It uses automake dependency generation so maybe it's the headers in the gcc directory, or something like that. The real question in my mind is why it's using the system compiler. Maybe we should use different install targets if any bootstrap stages have been created, and use POSTSTAGE1_FLAGS_TO_PASS for the recursive invocation (in which case, this probably applies to all the other targets, too). -- Daniel Jacobowitz CodeSourcery, LLC
Re: How to rebuild stage 1?
On Fri, Dec 16, 2005 at 09:35:22AM +0100, Paolo Bonzini wrote: > H. J. Lu wrote: > >How can I rebuild stage 1 compiler with the system compiler? I used > >to be able to do > > > ># cd gcc > ># make unstage1 > ># make restage1 > > > >But now ./prev-gcc/xgcc is used to build stage 1 compiler, not the > >system compiler. > > If the old bootstrap mechanism had already been garbage collected, you > would not have succeeded in doing "make unstage1" or "make restage1". > > What you want is, from the *toplevel* directory, "make all-stage1". I > can rename it to "make restage1" if people care enough, but I think the > new name fits more the toplevel Makefile's naming of targets (where you > have all-host, all-target, etc.). What we really need is more documentation in the top-level Makefile about the available targets and what they do, I think. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Hard to tell what stage the bootstrap is on
On Fri, Dec 16, 2005 at 10:16:49AM +0100, Paolo Bonzini wrote: > >At the moment, we do this deliberately to preserve debug information. > >However, once libgcc is moved out of to top level - hopefully along > >with the gcc-provided include files - then gcc can be a pure host > >directory, and we won't need to worry about this. > > Uhm, we'd still need to have prev-libgcc wouldn't we? I'm not so > positive that we can remove the prev-* thing entirely, though it's > possible that it can be restricted to the target libraries... Exactly what I was suggesting - we can run stage1/gcc, though, which will make it real obvious in the logs which stage we're building. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Huge compile time regressions
Daniel Berlin wrote: On Thu, 2005-12-15 at 00:48 +0100, Steven Bosscher wrote: Hi, Someone caused a >10% compile time regression yesterday for CSiBE, see http://www.csibe.org/draw-diag.php?branchid=mainline&flags=-Os&rel_flag=--none--&dataview=Timeline&finish_button=Finish&draw=sbs&view=1&basephp=l-sbs Gr. Steven This is very very bad. Joern, i'd imagine this was your patch. Seems to be. I can reproduce a massive compile-time difference (up to a 50% increase) between 108479 and 108480, but I'm having trouble figure out where exactly that time goes. Joern, please revert the patch for now. I'll be away for three weeks; if no one else works with you on this in the meantime I'll help once I'm back. Bernd
Re: Mainline profiledbootstrap broken
make[2]: Entering directory `/scratch/ogcc/stagefeedback-libcpp' gcc -I/scratch/gcc/libcpp -I. -I/scratch/gcc/libcpp/../include -I/scratch/gcc/libcpp/include -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -I/scratch/gcc/libcpp -I. -I/scratch/gcc/libcpp/../include -I/scratch/gcc/libcpp/include -c -o charset.o -MT charset.o -MD -MP -MF .deps/charset.Po /scratch/gcc/libcpp/charset.c cc1: warnings being treated as errors /scratch/gcc/libcpp/charset.c:1: warning: 'charset.gcda' is version '402e', expected version '400*' This is the same problem that Andrew reported http://gcc.gnu.org/ml/gcc/2005-12/msg00414.html and I am looking into it. Paolo
Mainline profiledbootstrap broken
Hi, maybe this is some fallout from the toplevel-bootstrap patch... I configured current mainline with $SRCDIR/configure --quiet --prefix=$DESTDIR --enable-languages=c++,fortran --with-gmp=/usr/local/appl/gmp-4.1.4 --enable-checking=release and the bootstrap stopped at make[2]: Entering directory `/scratch/ogcc/stagefeedback-libcpp' gcc -I/scratch/gcc/libcpp -I. -I/scratch/gcc/libcpp/../include -I/scratch/gcc/libcpp/include -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -I/scratch/gcc/libcpp -I. -I/scratch/gcc/libcpp/../include -I/scratch/gcc/libcpp/include -c -o charset.o -MT charset.o -MD -MP -MF .deps/charset.Po /scratch/gcc/libcpp/charset.c cc1: warnings being treated as errors /scratch/gcc/libcpp/charset.c:1: warning: 'charset.gcda' is version '402e', expected version '400*' make[2]: *** [charset.o] Error 1 make[2]: Leaving directory `/scratch/ogcc/stagefeedback-libcpp' make[1]: *** [install-libcpp] Error 2 make[1]: Leaving directory `/scratch/ogcc' make: *** [install] Error 2 I observed this on i686 and x86_64. Cheers, Martin
Re: make all vs make bootstrap
Paolo Bonzini <[EMAIL PROTECTED]> wrote: >> What about bubblestrap? >> >> (See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25438) >> >> > A "make" from a toplevel is equivalent to the old "make bubblestrap" > or "make -C bubblestrap". In practice "make" just does the right > thing, compiling all that is needed to not have comparison failures. I would also note that using "make" in the cp/ directory at least used to build cc1plus with the system compiler, without -Werror and with a different set of warnings. There have been many cases where a patch tested by C++ rules (which is *not* a full bootstrap, but just "build compiler, build libjava, check c++") resulted in a bootstrap failure because of a variable not initialized or something. The correct solution used to be (guess what!) "make bubblestrap" to build the compiler. Now, it's simply the default :) Giovanni Bajo
Re: Add revision number to gcc version?
> 1. contrib/gcc_update creates gcc/REVISION with branch name and > revision number. > 2. If gcc/REVISION exists, it will be used in gcc/version.c. > > With those 2 patches, I got > > [EMAIL PROTECTED] gcc]$ ./xgcc --version > xgcc (GCC) 4.1.0 (gcc-4_1-branch revision 108596) 20051215 (prerelease) [snip] > xgcc (GCC) 4.2.0 (trunk revision 108596) 20051215 (experimental) IMHO we should change the current naming system as little as possible for those who run scripts to extract the information from the compiler automatically. (Maybe I'm the only one, but I do.) Therefore I'd like to suggest to add the new stuff at the end and with brackets instead of parentheses to make that information easily extractable as well. xgcc (GCC) 4.1.0 20051215 (prerelease) [gcc-4_1-branch revision 108596] xgcc (GCC) 4.2.0 20051215 (experimental) [trunk revision 108596] Somebody on this thread also suggested to skip the date and only use the revision number. I don't think that this is a good idea, because 1.) there are scripts out there that rely on the date (OK, maybe I'm the only one) 2.) if we ever change the revision control system again, these numbers are probably obsolete 3.) the date carries a lot of information for humans (oh, this snapshot is already two month old, I should get a new one) without having to consult a database (for those who only download snapshots). And this info is available offline, too. Regards, Volker
RE: Compile-time / memory regression
Richard Guenther wrote: > Between Dec 12 and today there has been a ~10% compile-time regression > and a 1.3% memory usage regression on the tramp3d tester. Due to > bootstrap problems in between these days I cannot restrict the window > more. > > Richard. Already noted at http://gcc.gnu.org/ml/gcc/2005-12/msg00375.html but no resolution yet. cheers, DaveK -- Can't think of a witty .sigline today
Re: Compile-time / memory regression
> Richard Guenther writes: Richard> Between Dec 12 and today there has been a ~10% compile-time regression Richard> and a 1.3% memory usage regression on the tramp3d tester. Due to Richard> bootstrap problems in between these days I cannot restrict the window Richard> more. When Mark announced mainline open for GCC 4.2 work, he said: * Please announce major merges of new functionality 24 hours before the actual merge * Please allow 24 hours after a major merge before the next major merge * Please refrain from a major merge if we're currently experiencing serious stability problems that are being resolved from the previous merge. Developers are not following those requests. If developers cannot voluntarily implement the requests, more strict rules will have to be imposed. David
Re: What happened to bubblestrap?
Quoting Paolo Bonzini <[EMAIL PROTECTED]>: > Yes. "make bubblestrap" is now called simply "make". As Giovanni put > it a few minutes ago: > > "I would also note that using "make" in the cp/ directory at least used > to build cc1plus with the system compiler, without -Werror and with a > different set of warnings. There have been many cases where a patch > tested by C++ rules (which is *not* a full bootstrap, but just "build > compiler, build libjava, check c++") resulted in a bootstrap failure > because of a variable not initialized or something. The correct solution > used to be (guess what!) "make bubblestrap" to build the compiler. Now, > it's simply the default :)" Cool. Of course I didn't notice, because the first build after the switch was from scratch :-) - Tobi
Found error in g77 documentation
Hello, I found an error in g77 documentation. Sorry for wrting to this mail address, but I did not find anywhere in the bug reporting documentation how to report a bug on the...documentation itself In particular, here: http://gcc.gnu.org/onlinedocs/gcc-3.2.3/g77/Floating-point-Exception-Handling.html#Floating-point%20Exception%20Handling where it states: "... gcc -o libtrapfpe.a trapfpe.c and then use it by adding -trapfpe to the g77 command line when linking ..." Whe I try it I get /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/../../../crt1.o(.text+0x18): In function `_start': : undefined reference to `main' /tmp/ccC12cnM.o(.text+0xc): In function `trapfpe': : undefined reference to `feenableexcept' collect2: ld returned 1 exit status This is due to the fact that gcc does not produce an archive on the fly. One should do: gcc -c trapfpe.c ar rv libtrapfpe.a trapfpe.o Also linking is quoted incorrectly in the documentation. It should at least be "...-ltrapfpe..." ^ If there's a way I can contribute directly to the docs, please let me know. I'd gladly do it, just to give my 2 cents worth to the great GNU project. many thanks and best regards -- Matteo Boschini GPG Key Fingerprint: 63E4 AD0B 6F24 2345 789E 17AA BE94 CC44 CA7D E81E "Pardon our formality: we're computer scientists" (Lutz & Ascher)
Compile-time / memory regression
Between Dec 12 and today there has been a ~10% compile-time regression and a 1.3% memory usage regression on the tramp3d tester. Due to bootstrap problems in between these days I cannot restrict the window more. Richard.
Re: What happened to bubblestrap?
I just did a fresh build testing a patch here and then I try make bubblestrap and "no target 'bubblestrap' I'm curious myself. Was this an intentional result of the toplevel bootstrap stuff? Yes. "make bubblestrap" is now called simply "make". As Giovanni put it a few minutes ago: "I would also note that using "make" in the cp/ directory at least used to build cc1plus with the system compiler, without -Werror and with a different set of warnings. There have been many cases where a patch tested by C++ rules (which is *not* a full bootstrap, but just "build compiler, build libjava, check c++") resulted in a bootstrap failure because of a variable not initialized or something. The correct solution used to be (guess what!) "make bubblestrap" to build the compiler. Now, it's simply the default :)" I guess we now know that GCC developers update their tree about every 50-60 hours (most bug reports came in 25-30 hours after the switch). Paolo
Re: What happened to bubblestrap?
On 12/16/05, Tobias Schlüter <[EMAIL PROTECTED]> wrote: > > [ forwarding to gcc@gcc.gnu.org ] > > Jerry DeLisle wrote: > > I just did a fresh build testing a patch here and then I try make > > bubblestrap > > and "no target 'bubblestrap' > > I'm curious myself. Was this an intentional result of the toplevel bootstrap > stuff? see the thread today "make all vs make bootstrap" and Bonzini's reply to my question there. -- Cheers, /ChJ
Re: What happened to bubblestrap?
[ forwarding to gcc@gcc.gnu.org ] Jerry DeLisle wrote: > I just did a fresh build testing a patch here and then I try make bubblestrap > and "no target 'bubblestrap' I'm curious myself. Was this an intentional result of the toplevel bootstrap stuff? - Tobi
Re: Hard to tell what stage the bootstrap is on
At the moment, we do this deliberately to preserve debug information. However, once libgcc is moved out of to top level - hopefully along with the gcc-provided include files - then gcc can be a pure host directory, and we won't need to worry about this. Uhm, we'd still need to have prev-libgcc wouldn't we? I'm not so positive that we can remove the prev-* thing entirely, though it's possible that it can be restricted to the target libraries... Paolo
Re: make install is broken on powerpc-darwin starting with a 3.3 compiler
Andrew Pinski wrote: doing the following $(srcdir)/configure --prefix=${HOME}/libobjc.trunk --enable-languages=c,objc make all make -k check make install Why is it recompiling libcpp? That's the real bug. Please open a PR because the discussion really belongs in Bugzilla. Paolo
Re: make all vs make bootstrap
Christian Joensson wrote: What about bubblestrap? (See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25438) A "make" from a toplevel is equivalent to the old "make bubblestrap" or "make -C bubblestrap". In practice "make" just does the right thing, compiling all that is needed to not have comparison failures. Paolo
Re: make all vs make bootstrap
What about bubblestrap? (See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25438) -- Cheers, /ChJ
Re: make all vs make bootstrap
Will make quickstrap do the same as "make all"? No, there's no "make quickstrap" at all! Citing from the "Top-Level Bootstrap" wiki page: Toplevel bootstrap is able to bootstrap a compiler with separate reconfigurations and rebuilds of libiberty/libcpp/gcc in all the three stages. It is actually possible to bootstrap a whole toolchain, so that the final executable is built entirely with the assembler, binutils and linker that are in a combined tree. When configuring in a native environment, make will do more or less what make bubblestrap used to do: start from stage1, rebuild everything that had to be rebuilt, configure stage2 if it has not been configured yet, build stage2, and the same for stage3. "Rebuilding" is not limited to GCC: libiberty, libcpp, and other dependencies of GCC are all configured and compiled three times. It is the same as rebuilding a whole tree from scratch three times, each time using the previous build as the result. It supports all the bells and whistles like bubblestraps and restageN, which help during development. make restrap (taking a non-bootstrap build and using it as stage1) is not supported. make restageN is called make all-stageN, and there is also make all-stageN-gcc to rebuild gcc only. There is no equivalent to quickstrap, even though it can be added if there's demand. Lean bootstraps are also supported, but they are enabled with --enable-bootstrap=lean rather than with special targets. make profiledbootstrap works; it will build profile-optimized assemblers, binutils and linkers when run in a combined tree. For a while, old-style bootstrap will still be available with ./configure --disable-bootstrap; make bootstrap (non intuitive maybe, but in the long term, it would only be one more historic wart if the flag was called --{enable,disable}-toplevel-bootstrap). I *really* don't want to have to remember new configure options when this used to be a simple makefile target. I'm sorry, there's no alternative. The two bootstrap/non-bootstrap logics are very different. If they could live together in the gcc directory, and most of the time working, it was only at the price of comparison failures when you were doing something a bit more weird than what is supported. It's probably a matter of having different working patterns. Mine is that if bootstrap breaks seriously (e.g. with wrong code), I make a .i of the failure, move it to prev-gcc, and work from there. With the old bootstrapping logic I made the .i of the failure, typed "make restage1", and worked from there. The number of steps is the same. I agree that the "prev-gcc" naming is sub-ideal, but Daniel seems confident that it can be fixed after his toplevel libgcc work goes in. If that's true, we can actually do *entirely without* the unstage/stage mess and simply have build directories that are called "stage1-gcc", "stage2-gcc", "stage3-gcc". This will make things even easier. But please, let me recall that the first CFT for toplevel bootstrap (when everything was working except parallel builds, and bootstrapping combined trees) is from September 2004. Paolo
Re: How to rebuild stage 1?
H. J. Lu wrote: How can I rebuild stage 1 compiler with the system compiler? I used to be able to do # cd gcc # make unstage1 # make restage1 But now ./prev-gcc/xgcc is used to build stage 1 compiler, not the system compiler. If the old bootstrap mechanism had already been garbage collected, you would not have succeeded in doing "make unstage1" or "make restage1". What you want is, from the *toplevel* directory, "make all-stage1". I can rename it to "make restage1" if people care enough, but I think the new name fits more the toplevel Makefile's naming of targets (where you have all-host, all-target, etc.). Paolo
Re: GCC mailing list archive search omits results after May 2005
Ranjit Mathew <[EMAIL PROTECTED]> writes: > Yes it does. If nothing else, the archives are used to > provide canonical URLs for referring to messages. gmane provides that too.