Re: Call for port conversions to MD define_constraint
On Fri, 2007-05-25 at 12:41 -0700, Zack Weinberg wrote: > but there are still a lot left to go: > > arc bfin c4x cris crx fr30 frv h8300 iq2000 m32c m32r m68hc11 mcore mmix > mn10300 mt pa pdp11 score sh sparc stormy16 v850 vax I can provide the patch for arc sometime soon regards saurabh
How to enable Mudflap in gcc 4.x?
Hi, I am building the C/C++ GCC toolchain for i386 target on x86/Linux platform. The native gcc version is "gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)" and the version of the sources are: GCC : gcc-4.3-20070302 Binutils : binutils-070204 Newlib : newlib-1.15.0 To enable libmudflap library, I am passing the "--enable-libmudflap" option in the gcc configure script But I get the following error during final gcc building: "configure error: none of the known symbol names works [configure-target-libmudflap] Error 1" What can be reason for this failure? Are some additional options required to be added in the configure script to enable the libmudflap library? Regards, Deepen Mantri KPIT Cummins InfoSystems Ltd. Pune, India Free download of GNU based tool-chains for Renesas' SH, H8, R8C, M16C and M32C Series. The following site also offers free technical support to its users. Visit http://www.kpitgnutools.com for details. Latest versions of KPIT GNU tools were released on February 6,07
Re: How to enable Mudflap in gcc 4.x?
On 5/28/07, Deepen Mantri <[EMAIL PROTECTED]> wrote: Hi, I am building the C/C++ GCC toolchain for i386 target on x86/Linux platform. The native gcc version is "gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)" and the version of the sources are: GCC : gcc-4.3-20070302 Binutils : binutils-070204 Newlib : newlib-1.15.0 To enable libmudflap library, I am passing the "--enable-libmudflap" option in the gcc configure script But I get the following error during final gcc building: "configure error: none of the known symbol names works [configure-target-libmudflap] Error 1" What can be reason for this failure? Are some additional options required to be added in the configure script to enable the libmudflap library? Regards, Deepen Mantri KPIT Cummins InfoSystems Ltd. Pune, India Free download of GNU based tool-chains for Renesas' SH, H8, R8C, M16C and M32C Series. The following site also offers free technical support to its users. Visit http://www.kpitgnutools.com for details. Latest versions of KPIT GNU tools were released on February 6,07 i think gcc-help is suitable for you. Best Regards -- i'm a newbie in GCC community. Wei Chen
Loop information reuse for machine dependent reorg pass
Hi, I'm working on a new gcc port for which I'm writing a loop reorganization as a part of the machine dependant pass. This reorg requires information regarding the number of iterations in each loop. I tried to rebuild current_loops and extract the info from there using different loop initialization passes but noticed that the loop iterations are calculated in several different passes. I am also hesitant in re-running these passes as I don't want to cause unwanted side effects. I was interested in learning if there is an accepted method for acquiring this information. Regards and thanks in advance, Yoav Teboulle
Re: Volunteer for bug summaries?
On Wed, May 23, 2007 at 10:02:02AM -0700, Joe Buck wrote: > Mark Mitchell wrote: > > >1. Add a field to bugzilla for the SVN revision at which a particular > > >regression was introduced. Display that in bugzilla as a link to the > > >online SVN history browser so that clicking on a link takes us from the > > >PR straight to the checkin. This field value ought to be the most > > >recent revision to the GCC trunk such that the bug did not occur in the > > >previous revision, but does occur in all subsequent revisions. > The Bugzilla field is just a string, so it's possible to put a > range there as well as a single number. A link to the SVN log of the range for the file which is assumed to be the buggy one would be useful too. -- Rask Ingemann Lambersen
Re: help required for upgradation of gcc-4.1.1
3. ./configure Read the instructions. Building in the source directory is not supported. Often buggy and thus not suggested, but in principle supported. Paolo
Bugzilla wishes (Was: Volunteer for bug summaries?)
On Wed, May 23, 2007 at 02:06:21PM -0400, Daniel Berlin wrote: > I have to look into bugzilla 3.0 migration first though. Bugzilla 3.0 > introduces a custom fields mechanism, and i'd rather at least store > our data using that, than editing the schema wholesale like we do now > (which is *much* harder to port between versions of bugzilla, and one > of the reason we've had trouble keeping up). Bug reports have build, host and target fields. Search results show just the host field, which is rarely of any use. I think it would be great if instead the target field were shown. Build system maintainers might want to see the build field instead. -- Rask Ingemann Lambertsen
Re: Bugzilla wishes (Was: Volunteer for bug summaries?)
On 5/28/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: On Wed, May 23, 2007 at 02:06:21PM -0400, Daniel Berlin wrote: > I have to look into bugzilla 3.0 migration first though. Bugzilla 3.0 > introduces a custom fields mechanism, and i'd rather at least store > our data using that, than editing the schema wholesale like we do now > (which is *much* harder to port between versions of bugzilla, and one > of the reason we've had trouble keeping up). Bug reports have build, host and target fields. Search results show just the host field, which is rarely of any use. I think it would be great if instead the target field were shown. Build system maintainers might want to see the build field instead. You can customize what fields are shown on the search results, if you like. It used to be the target field, but it was requested to change it to the the host field. -- Rask Ingemann Lambertsen
Re: Failure during bootstrap for libjava on powerpc linux
"H. J. Lu" <[EMAIL PROTECTED]> wrote on 27/05/2007 21:00:38: > On Sun, May 27, 2007 at 06:52:30PM +0100, Rafael Espindola wrote: > > On 5/27/07, Razya Ladelsky <[EMAIL PROTECTED]> wrote: > > >Hi, > > > > > >Getting failure during bootstrap for libjava on powerpc linux: > > > > > >configure: error: `CXX' has changed since the previous run: > > >configure: former value: /home2/razya/matrix_copy/build/./gcc/xgcc > > > > > > Same problem on linux x86_64 > > > > See > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078 > > > H.J. Thanks Razya
[wwwdocs PATCH] RE: gcc-4.2 manuals: GNU OpenMP Manual?
On Thu, 17 May 2007, Dave Korn wrote: >> Should section "GCC 4.2.0 manuals" of >> >> http://gcc.gnu.org/onlinedocs/ >> >> not also list the "GNU OpenMP Manual" that is available for 4.2? > Yes, it probably should. The released docs have been prepared correctly: > http://gcc.gnu.org/onlinedocs/gcc-4.2.0/libgomp > is live. I went ahead and committed the patch below. Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/onlinedocs/index.html,v retrieving revision 1.87 diff -u -3 -p -r1.87 index.html --- index.html 14 May 2007 21:17:36 - 1.87 +++ index.html 28 May 2007 13:05:36 - @@ -60,6 +60,13 @@ href="http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gnat_ugn_unw.ps.gz";>PostScript or http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gnat_ugn_unw-html.tar.gz";>an HTML tarball) +http://gcc.gnu.org/onlinedocs/gcc-4.2.0/libgomp/";>GCC 4.2.0 + GNU OpenMP Manual (http://gcc.gnu.org/onlinedocs/gcc-4.2.0/libgomp.pdf";>also in + PDF or http://gcc.gnu.org/onlinedocs/gcc-4.2.0/libgomp.ps.gz";>PostScript or http://gcc.gnu.org/onlinedocs/gcc-4.2.0/libgomp-html.tar.gz";>an + HTML tarball) http://gcc.gnu.org/onlinedocs/gcc-4.2.0/docs-sources.tar.gz";>Texinfo sources of all the GCC 4.2.0 manuals
Target Hook not getting recognized - GCC 4.1.1
Hi all, I have defined a target hook TARGET_EXPAND_BUILTIN_SAVEREGS (GCC 4.1.1) as an alternative to TARGET_SETUP_INCOMING_VARARGS so as to code ___builtin_saveregs as per my target. But this target hook is not getting recognized. Is there anything else this target hook depends on? Regards, Rohit
Re: Call for port conversions to MD define_constraint
On Fri, May 25, 2007 at 12:41:32PM -0700, Zack Weinberg wrote: > I see that many of > the more popular CPUs have already been done: > >alpha arm avr i386 ia64 m68k mips rs6000 s390 spu xtensa > > but there are still a lot left to go: > >arc bfin c4x cris crx fr30 frv h8300 iq2000 m32c m32r m68hc11 mcore mmix >mn10300 mt pa pdp11 score sh sparc stormy16 v850 vax Just in case you've forgotten: You posted a patch for h8300 here: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html> > If all ports are converted by, oh, the beginning of August, I'll find > time to implement the precalculation of constraint sets for reload and > recog. What is the status of automatically generating documentation for the constraints? -- Rask Ingemann Lambertsen
Re: Bribing a reviewer
On Fri, May 25, 2007 at 09:26:35PM +0200, Thomas Neumann wrote: > > Therefore I am offering a deal to potential reviewers: If you promise to > review some of my patches, I will code something _you_ care about. > Within reasonable limits, of course :) A more traditional approach would be to use the patch tracker http://gcc.gnu.org/wiki/GCC_Patch_Tracking>, just in case a reviewer is looking for something to review. And when posting a patch, try to make it easy for reviewers to tell that your patch is for their part of GCC. For example, how does a reload maintainer know that http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01774.html> is a patch for reload? I suggest adding the word "reload" somewhere on the subject line, perhaps as [reload] if there isn't a natural way of including it on the subject line. -- Rask Ingemann Lambertsen
Re: Bribing a reviewer
> looking for something to review. And when posting a patch, try to make it > easy for reviewers to tell that your patch is for their part of GCC. I see your point. I originally thought I would be sending one patch for whole gcc (as I have the complete patch ready), just broken into smaller parts for reviewing. Therefore I called them "C++ compatibility". But I will name the mails more according to the content in the future. (And send pings with more reasonable names, too). >A more traditional approach would be to use the patch tracker > http://gcc.gnu.org/wiki/GCC_Patch_Tracking>, just in case a reviewer is I tried this for a few patches, but I have some problems finding out what area I should write there... But I will try to improve my patches. Thanks for your suggestions. Thomas
Re: Mercurial repository (Mirrored from SVN trunk) now publicly available
On 5/27/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: Oh, some more details for those who want them: The repo contains the complete history of gcc trunk (125000 svn revisions). It takes roughly 350 meg of disk space (450 on mac due to inode size). Curiosity, any plans to convert the full gcc repository (including branches and tags)? Thanks, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
Re: Call for port conversions to MD define_constraint
On 5/28/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: Just in case you've forgotten: You posted a patch for h8300 here: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html> Yes, but it's got bugs, and it will be more efficient for an actual h8300 expert to fix them than for me to struggle with the buggy h8300 simulator toolchain any more. What is the status of automatically generating documentation for the constraints? That is one of the things I might consider coding up once all ports are converted. I would be much more inclined to bother if the Steering Committee managed to persuade RMS to GPL the manuals. zw
Re: Bribing a reviewer
On Mon, May 28, 2007 at 07:04:01PM +0200, Thomas Neumann wrote: > I see your point. I originally thought I would be sending one patch for > whole gcc (as I have the complete patch ready), just broken into smaller > parts for reviewing. If possible, 1) Break patches up into parts which can be applied individually without breaking anything. If they must be applied in a specific order, say so. 2) Break patches up into parts each needing only one maintainer's approval. E.g. your patch covering reload.h, reload.c and reload1.c is fine in this regard. [patch tracker] > I tried this for a few patches, but I have some problems finding out > what area I should write there... Approximately the same as you'd use in the subject line. I would use the MAINTAINERS file and the bug database component field as a guide. -- Rask Ingemann Lambertsen
[CFARM] gmp, mpfr and GNU make on gcc04
I have built and installed gmp, mpfr and GNU make on gcc04 using --prefix=/home/rask/opt, so you can build GCC if you pass --with-gmp=/home/rask/opt --with-mpfr=/home/rask/opt to configure. You will need let the dynamic linker know this: export LD_LIBRARY_PATH=/home/rask/opt/lib GNU make is available as /home/rask/opt/bin/make. Source tarballs are in /n/07/guerby/ftp. Finally, using two existing baseboard files as a starting point, I made /home/rask/dejagnuboards/m32c-sim.exp for running tests of --target=m32c-unknown-elf. -- Rask Ingemann Lambertsen
Re: Mercurial repository (Mirrored from SVN trunk) now publicly available
On 5/28/07, Rafael Espindola <[EMAIL PROTECTED]> wrote: On 5/27/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > Oh, some more details for those who want them: > > The repo contains the complete history of gcc trunk (125000 svn revisions). > > It takes roughly 350 meg of disk space (450 on mac due to inode size). Curiosity, any plans to convert the full gcc repository (including branches and tags)? Errr, i may convert active branches if we decide to move, but there is no point in doing so now. I also doubt it makes sense to keep all active branches in the same repository with mercurial
[CFARM] First hardware upgrade for the compile farm ordered
Thanks to those who advised on hardware. FSF France has ordered 3x Dell SC1345, bi-Opteron 2212 (dual core 2GHz) with 4GB of RAM and plenty of disk, these should be in place sometimes in june and at least three of the old Pentium 3 Dell will be removed from the farm. OS will likely be debian this time, existing accounts will be maintained (we'll probably need to pack/clean some files for the migration). Remaining money should be enough to buy an additional bi-Xeon quad core from supermicro (6015V-TLP), order will be passed when I find a vendor who does ship to Paris, France with reasonable delay (if you know who to talk to and who to avoid let me know privately ASAP). Then all the old Dell will be removed from the farm. Instructions and conditions to get an account on the farm here: http://gcc.gnu.org/wiki/CompileFarm Since I've been asked: you can apply for an account even if you're not testing GCC but just testing free software with GCC releases or trunk versions (only constraint on the farm is minimal network bandwidth use). Laurent
POINTER_PLUS branch status?
Andrew -- I'm trying to firm up GCC 4.3 planning a bit. One of the things I'm considering is whether or not the POINTER_PLUS branch should be merged as part of 4.3. My understanding from looking at your emails is that the branch is in pretty good shape. Would you please give me a summary of the status? Are there regressions on major platforms? Also, does anyone feel that this representation change is a bad thing? Are there any objections to merging this branch in principle, assuming that it's not causing regressions, either in generate code or at compile time? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Fixed-point branch?
Joseph, Richard -- As C maintainers, have either of you looked at Chao-Ying's fixed-point branch? My understanding (from the note on the Wiki page) is that the fixed-point support is now in reasonably good shape, and works on all architectures, using an emulation library. So, I'm wondering if we should get this into GCC 4.3. I'm interested in your impressions of: (a) whether implementing N1169 is likely to be dangerous, in the sense that the committee might eventually adopt a substantially conflicting version of the specification, (b) the quality of the implementation, (c) risks you would forsee to other parts of the compiler. For the purposes of this discussion, I'm less interested in your impressions (if any) of the MIPS back-end changes; those can be looked at by a MIPS maintainer in due course. The first step would be to get this functionality into the C front-end. Chao-Ying, I'm also interested in whether or not these changes have any impact on C++. With your changes, does GNU C++ now accept any fixed-point constructs? If so, are you aware of any effort to standardize any of this functionality in C++? (I think that my preference, in the short term, would be to disable this functionality in C++ -- although, of course, we will eventually want to turn it on so that GNU C++ is as much as possible a superset of GNU C.) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
gcc-4.1-20070528 is now available
Snapshot gcc-4.1-20070528 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070528/ 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 125150 You'll find: gcc-4.1-20070528.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070528.tar.bz2 C front end and core compiler gcc-ada-4.1-20070528.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070528.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070528.tar.bz2 C++ front end and runtime gcc-java-4.1-20070528.tar.bz2 Java front end and runtime gcc-objc-4.1-20070528.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070528.tar.bz2The GCC testsuite Diffs from 4.1-20070521 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.
GCC 4.1.x Status Report (2007-05-28)
At this point, I do not plan to do any further GCC 4.1.x releases. The GCC 4.1.x series was a great success, and is very widely used. I think it's a fine idea for people to continue to apply fixes to the 4.1.x branch, under the usual release-branch rules, so that people interested in longer-term use of GCC 4.1.x can update from there. And, I would of course be happy to turn the branch over to someone else, if there is interest in future releases. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.2.1 Status Report (2007-05-28)
I would like to try to keep the GCC 4.2.x release branch on the time-driven release cycle for point releases that is part of the GCC development plan. I left an embarrassing gap in the GCC 4.1.x release cycle, and I plan to avoid that mistake for GCC 4.2.x. Therefore, I plan to make the GCC 4.2.1 release on or about July 13th. As with the 4.2.0 release, I will be most concerned about P1 regressions in 4.2.x, not present in 4.1.x. At present, that looks to be: * PR 30252 miscompilation of sigc++-2.0 based code with -fstrict-aliasing * PR 31360 rtl loop invariant is broken This is a missed-optimization problem, fixed on the mainline -- although the audit trail suggests that there are unresolved problems on ARM, including bad code generation and CSiBE regressions. There are currently 128 P3-and-higher regressions from previous GCC releases that apply to the 4.2 branch. In order to actually make the release July 13th, I've put a note in my calendar to make 4.2.1 RC1 on July 1st. If there are 4.2.x regressions that you're interested in fixing, please do your best to fix them by that date. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.3.0 Status Report (2007-05-28)
Now that GCC 4.2.0 is finally out the door, I'm looking at 4.3.0. Stage 1 has been going on a *long* time, and there have been a lot of changes made. (The Wiki page has an impressive list.) We also seem to have the dataflow stuff ready for merge to mainline, and it looks like POINTER_PLUS may also be close. Unfortunately, we've also introduced a lot of regressions: there look to be about 40 new 4.3-only regressions. The combination of those factors (long Stage 1, lots of new infrastructure already in, lots of new regressions) suggests to me that it's time to bring Stage 1 to a close. Therefore, my current thinking is to close Stage 1 on July 1st, giving everyone one more month to push in any major changes. (Even though it's been a long Stage 1, I don't want to make things overly abrupt.) However, I'm certainly open to suggestions. If you feel that's going to exclude some very important functionality, let me know. If you feel that's too long, let me know that too. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.1 Status Report (2007-05-28)
On Mon, May 28, 2007 at 03:48:39PM -0700, Mark Mitchell wrote: > Therefore, I plan to make the GCC 4.2.1 release on or about July 13th. > As with the 4.2.0 release, I will be most concerned about P1 regressions > in 4.2.x, not present in 4.1.x. At present, that looks to be: > > * PR 30252 miscompilation of sigc++-2.0 based code with -fstrict-aliasing > > * PR 31360 rtl loop invariant is broken PR 30052 (GCC 4.2 can't compile xorg-server, memory hog problem) is only a P2 regression, but I guess is prevents GCC 4.2.x from being used in most distributions. -- Rask Ingemann Lambertsen
Re: POINTER_PLUS branch status?
On 5/28/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Andrew -- Would you please give me a summary of the status? Are there regressions on major platforms? The summary is that powerpc-darwin, powerpc64-linux-gnu, spu-elf, i686-linux-gnu bootstraps and tests with two regression (explained below). sh-linux-gnu and x86_64-linux-gnu are known to bootstrap (but I have not seen the testresults to know if they have any other regressions on those targets), There are two regressions on all targets which support vectorizer of integers. These two regressions in the vectorizer testsuite which are caused by forwprop finally doing a better job and transforming &a->b[0] p+ (i + 1)*4 and data-ref not understanding this change; I am testing the fix for one of the two regressions currently for the mainline (I was able to make a testcase which shows the problem for the mainline for both issues, see PR 32075 and PR 31996). For the second one I am thinking about just adding an extra forwprop to fix up the issue and then let my current patch for data-ref fix that issue. Richard Guenther tested it on SPEC and the other benchmark for me and found that gzip was regressing a bit but I have not looked into that issue yet as I don't have access to x86_64 to figure out what is going on. I cleaned up the code today so it basically ready to be merged, some (most?) of the target headers still need to be fixed for the change. The list of targets which need to be changed is: alpha ia64 mips pa s390sparcstormy16xtensa I don't have access to any of those targets (and I have not built a sim based compiler yet). I would like help converting those last 8, the patch should mirror what was done for rs6000, spu or sh. Thanks, Andrew Pinski
