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.
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: 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: 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
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 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: 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: 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: 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?
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
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.
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)
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
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: 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: 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: 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
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: 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
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=mainlineflags=-Osrel_flag=--none--dataview=Timelinefinish_button=Finishdraw=sbsview=1basephp=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: 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: 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: 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
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
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
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
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: 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 :)
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: 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.
[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: 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
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: 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 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=$(DATESTAMP_s) \
+ -DREVISION=$(REVISION_s) \
-DDEVPHASE=$(DEVPHASE_s) -c $(srcdir)/version.c $(OUTPUT_OPTION)
gtype-desc.o: gtype-desc.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \
--- gcc/version.c.rev 2005-11-04 14:14:18.0 -0800
+++ gcc/version.c 2005-12-16 07:51:30.0 -0800
@@ -20,6 +20,7 @@
const char bug_report_url[] = URL:http://gcc.gnu.org/bugs.html;
/* The complete version string, assembled from
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
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: 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
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: 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 rearnsha at arm dot com To: tm_gccmail at mail dot kloo dot net Cc: Jon Beniston jbeniston at compxs dot com, 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
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: 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.
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: 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
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 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: 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 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
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.
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 --
http://gcc.gnu.org/onlinedocs/gcc/ is 403
$subject - since a day now. Richard. -- Richard Guenther richard dot guenther at uni-tuebingen dot de WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
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.
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: 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: 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
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 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
[Bug bootstrap/25435] stage build no longer works
--- Comment #3 from paolo dot bonzini at lu dot unisi dot ch 2005-12-16 08:02 --- Subject: Re: stage build no longer works hjl at lucon dot org wrote: --- Comment #2 from hjl at lucon dot org 2005-12-16 07:37 --- I made a change to i386.c. I just want to rebuild the final compiler with the stage 2 compiler. I don't want to rebootstrap the whole gcc. What should I do? You can do make all-stage3 (which is the new name of restageN). Or just do make which will do the equivalent of a bubblestrap (it does not recompile everything, but it does percolate the change through the whole set of stages, so that you do not get spurious comparison failures). Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25435
[Bug bootstrap/25438] make: *** No rule to make target `bubblestrap'. Stop.
--- Comment #1 from bonzini at gnu dot org 2005-12-16 09:00 --- 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. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25438
[Bug rtl-optimization/24823] [4.1/4.2 Regression] ICE in insert_save, at caller-save.c:719
--- Comment #21 from krebbel at gcc dot gnu dot org 2005-12-16 09:02 --- Subject: Bug 24823 Author: krebbel Date: Fri Dec 16 09:02:49 2005 New Revision: 108631 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108631 Log: 2005-12-16 Andreas Krebbel [EMAIL PROTECTED] PR 24823 * flow.c (mark_used_dest_regs): New function. (mark_used_regs): Call mark_used_dest_regs. 2005-12-16 Andreas Krebbel [EMAIL PROTECTED] PR 24823 * gfortran.dg/pr24823.f: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/pr24823.f Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/flow.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
[Bug libfortran/25349] T edit descriptor broken for output on files
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2005-12-16 09:04 --- Patch submitted for review and approval. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25349
[Bug fortran/25264] write to internal unit from the string itself gives wrong result ?
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2005-12-16 09:05 --- Patch submitted for review and approval. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25264
[Bug rtl-optimization/24823] [4.1/4.2 Regression] ICE in insert_save, at caller-save.c:719
--- Comment #22 from krebbel at gcc dot gnu dot org 2005-12-16 09:09 --- Subject: Bug 24823 Author: krebbel Date: Fri Dec 16 09:09:37 2005 New Revision: 108632 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108632 Log: 2005-12-16 Andreas Krebbel [EMAIL PROTECTED] PR 24823 * flow.c (mark_used_dest_regs): New function. (mark_used_regs): Call mark_used_dest_regs. 2005-12-16 Andreas Krebbel [EMAIL PROTECTED] PR 24823 * gfortran.dg/pr24823.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr24823.f Modified: trunk/gcc/ChangeLog trunk/gcc/flow.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
[Bug rtl-optimization/24823] [4.1/4.2 Regression] ICE in insert_save, at caller-save.c:719
--- Comment #23 from krebbel at gcc dot gnu dot org 2005-12-16 09:18 --- Fixed. -- krebbel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
[Bug driver/20425] -print-search-dirs doesn't honor mutil-os/multilib settings
--- Comment #10 from amodra at gcc dot gnu dot org 2005-12-16 09:46 --- Subject: Bug 20425 Author: amodra Date: Fri Dec 16 09:46:22 2005 New Revision: 108635 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108635 Log: PR driver/20425 * gcc.c (for_each_path): New function. (add_to_obstack, file_at_path): New functions. (struct file_at_path_info, struct add_to_obstack_info): New. (build_search_list): Rewrite using for_each_path. Constify struct path_prefix pointer. Add do_multi param. Adjust all callers. (find_a_file): Similarly, but just change existing param to bool. (putenv_from_prefixes): Add do_multi param, make paths const. (do_spec_path): Delete. (struct spec_path_info): New. (spec_path): New function. (do_spec_1): Use for_each_path for %D and %I. (find_file): Adjust for find_a_file changes. (main): Search multilibs for specs. Print multilib lib path for -print-search-dirs. Likewise add multilibs to LIBRARY_PATH_ENV. (read_specs): Search multilibs for %include and %include_noerr. (is_directory): Remove second string param. Change last param to a bool. Don't use concat. Remove SMALL_ARG_MAX test, always check path is a dir. Update all callers. * doc/hostconfig.texi (SMALL_ARG_MAX): Remove mention. * system.h (SMALL_ARG_MAX): Poison. * config.gcc: Don't define SMALL_ARG_MAX. * config.host: Likewise. * config.build: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config.build trunk/gcc/config.gcc trunk/gcc/config.host trunk/gcc/doc/hostconfig.texi trunk/gcc/gcc.c trunk/gcc/system.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425
[Bug driver/20425] -print-search-dirs doesn't honor mutil-os/multilib settings
--- Comment #11 from amodra at bigpond dot net dot au 2005-12-16 09:49 --- Fixed mainline. -- amodra at bigpond dot net dot au changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2005- |patches/2005- |12/msg00607.html|12/msg00818.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425
[Bug java/24698] [4.1/4.2 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key
--- Comment #14 from bero at arklinux dot org 2005-12-16 09:59 ---
This happens 100% reproducably when using ResourceBundle.getString on an
existing bundle with a nonexistant key -- this is enough to reproduce, no need
for an external jar or anything:
===
import java.util.*;
class test {
public static void main(String args[]) {
ResourceBundle
bundle=ResourceBundle.getBundle(gnu.java.locale.LocaleInformation);
bundle.getString(This key does not exist.);
}
}
===
Note that using getObject instead of getString works.
--
bero at arklinux dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698
[Bug target/25428] arm-elf-gcc generating wrong code with -O flag at functions with __attribute__ ((interrupt (IRQ)))
--- Comment #7 from th dot r dot klein at web dot de 2005-12-16 11:31 --- To me it looks like, that this patch also fixes Bug #16634 But I might be wrong, here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25428
[Bug target/25428] arm-elf-gcc generating wrong code with -O flag at functions with __attribute__ ((interrupt (IRQ)))
--- Comment #8 from th dot r dot klein at web dot de 2005-12-16 11:34 --- Created an attachment (id=10513) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10513action=view) working: arm-elf-gcc -save-temps -mthumb-interwork -mapcs-frame -O -march=armv4t -Wall -c except.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25428
[Bug target/25428] arm-elf-gcc generating wrong code with -O flag at functions with __attribute__ ((interrupt (IRQ)))
--- Comment #9 from th dot r dot klein at web dot de 2005-12-16 11:35 --- Created an attachment (id=10514) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10514action=view) working: arm-elf-gcc -save-temps -mthumb-interwork -mno-apcs-frame -O -march=armv4t -Wall -c except.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25428
[Bug c++/25411] Optimization with -O2 -finline-functions gives wrong code
--- Comment #4 from hans dot ekkehard dot plesser at umb dot no 2005-12-16 11:50 --- (In reply to comment #3) I cannot reproduce this on alphaev68-linux with 4.0.3 20051201 (prerelease), 4.1.0 20051124 (prerelease), or 4.2.0 20051124 (experimental). Could you perhaps try a newer version (4.0.2) or even better a recent snapshot? The bug occurs under release version 4.0.2 on alphaev7-dec-osf5.1b. It does NOT occur under gcc version 4.0.3 20051208 (prerelease) gcc version 4.1.0 20051209 (prerelease) I have not managed a complete build of 4.2.0. Hans -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25411
[Bug rtl-optimization/24899] [4.1/4.2 Regression] loop.c miscompiles libgnomecanvas
--- Comment #24 from jakub at gcc dot gnu dot org 2005-12-16 12:12 --- Subject: Bug 24899 Author: jakub Date: Fri Dec 16 12:12:41 2005 New Revision: 108642 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108642 Log: PR rtl-optimization/24899 * loop.c (strength_reduce): Don't reduce giv that is not always computable and where add_val or mult_val can trap. * gcc.c-torture/execute/20051215-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20051215-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
[Bug rtl-optimization/24899] [4.1/4.2 Regression] loop.c miscompiles libgnomecanvas
--- Comment #25 from jakub at gcc dot gnu dot org 2005-12-16 12:14 --- Subject: Bug 24899 Author: jakub Date: Fri Dec 16 12:14:15 2005 New Revision: 108643 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108643 Log: PR rtl-optimization/24899 * loop.c (strength_reduce): Don't reduce giv that is not always computable and where add_val or mult_val can trap. * gcc.c-torture/execute/20051215-1.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/20051215-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/loop.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
[Bug c++/25439] New: [4.0/4.1/4.3 regression] template int A0 accepted
The following invalid code snippet is accepted since GCC 4.0.0: templateint struct A; template int A0; Before we got the error message: bug.cc:2: error: `A0' specified as declarator-id bug.cc:2: error: extraneous `int' ignored -- Summary: [4.0/4.1/4.3 regression] template int A0 accepted Product: gcc Version: 4.0.2 Status: UNCONFIRMED Keywords: accepts-invalid, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25439
[Bug java/24698] [4.1/4.2 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key
--- Comment #15 from bero at arklinux dot org 2005-12-16 13:22 --- Created an attachment (id=10515) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10515action=view) Workaround patch The problem is with implicit exception handling. A slight modification to libjava (making the exception explicit) fixes it and makes all the problematic code (including the full ecj) work. Patch attached, but unless my understanding of Java exceptions is wrong (which might be, given I'm a C/C++ programmer), this just hides the effects of the real problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698
[Bug target/25440] New: [4.0 only] failure in gcc.dg/tls/pr24428.c with -fpic/-fPIC on x86_64
With the 4.0 branch, I'm getting a testsuite execution failure in gcc.dg/tls/pr24428.c when using -fpic/-fPIC on x86_64-unknown-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00893.html I don't see the problem in 4.1 or mainline -- Summary: [4.0 only] failure in gcc.dg/tls/pr24428.c with -fpic/- fPIC on x86_64 Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25440
[Bug rtl-optimization/25432] [4.1/4.2 Regression] Reload ICE in gen_add2_insn
--- Comment #5 from jakub at gcc dot gnu dot org 2005-12-16 13:59 --- Yeah, verified on the original testcase https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175766#c1 Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25432
[Bug middle-end/25441] New: -fpic/-fPIC failure in gcc.dg/pr23911.c
I'm getting a testsuite failure in 4.1/mainline in gcc.dg/pr23911.c on x86_64 and i686: http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00892.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00889.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00891.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00888.html The testsuite logfile says: FAIL: gcc.dg/pr23911.c scan-tree-dump-times = CR 0 FAIL: gcc.dg/pr23911.c scan-tree-dump-times = CI 0 -- Summary: -fpic/-fPIC failure in gcc.dg/pr23911.c Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org OtherBugsDependingO 23224 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25441
[Bug middle-end/25442] New: -fpic/-fPIC failures in gcc.dg/ipa/ipa-1.c ipa-2.c ipa-3.c ipa-4.c ipa-5.c
I'm getting testsuite failures when using -fpic/-fPIC with 4.1 and mainline in gcc.dg/ipa/ipa-1.c ipa-2.c ipa-3.c ipa-4.c ipa-5.c on x86_64 and i686: http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00892.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00889.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00891.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00888.html The failures look like this: FAIL: gcc.dg/ipa/ipa-1.c scan-ipa-dump-times versioned function 2 FAIL: gcc.dg/ipa/ipa-1.c scan-ipa-dump-times propagating const 2 FAIL: gcc.dg/ipa/ipa-2.c scan-ipa-dump-times versioned function 2 FAIL: gcc.dg/ipa/ipa-2.c scan-ipa-dump-times propagating const 2 FAIL: gcc.dg/ipa/ipa-3.c scan-ipa-dump-times versioned function 2 FAIL: gcc.dg/ipa/ipa-3.c scan-ipa-dump-times propagating const 3 FAIL: gcc.dg/ipa/ipa-4.c scan-ipa-dump-times versioned function 1 FAIL: gcc.dg/ipa/ipa-4.c scan-ipa-dump-times propagating const 1 FAIL: gcc.dg/ipa/ipa-5.c scan-ipa-dump-times versioned function 2 FAIL: gcc.dg/ipa/ipa-5.c scan-ipa-dump-times propagating const 2 -- Summary: -fpic/-fPIC failures in gcc.dg/ipa/ipa-1.c ipa-2.c ipa- 3.c ipa-4.c ipa-5.c Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org OtherBugsDependingO 23224 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25442
[Bug rtl-optimization/23837] [4.0/4.1/4.2 regression] Wrong code with REG_NO_CONFLICT notes (caused by combine)
--- Comment #28 from amylaar at gcc dot gnu dot org 2005-12-16 14:37 --- (In reply to comment #25) Smarter folks than me (iant ;-) suggest that a multi-word rotate will normally need all the input bits when setting any of the output bits, so the entire no-conflict thing doesn't make sense here. This is not really relevant, since the the insns that are using other words than the result word are computing their (intermediate) results into pseudos, and thus get emitted in front of (i.e. outside) the REG_NO_CONFLICT block. combine is really to blame for combining insns into a REG_NO_CONFLICT block in a way to invalidate the REG_NO_CONFLICT note without removing the note. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug middle-end/25443] New: -fpic/-fPIC failure in gcc.dg/tree-ssa/loop-3.c
I'm getting a 4.1/mainline failure in gcc.dg/tree-ssa/loop-3.c on x86_64 and i686: http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00892.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00889.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00891.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00888.html The failures look like this: FAIL: gcc.dg/tree-ssa/loop-3.c scan-tree-dump-times step: 1 -- Summary: -fpic/-fPIC failure in gcc.dg/tree-ssa/loop-3.c Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org OtherBugsDependingO 23224 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25443
[Bug middle-end/25444] New: -fpic/-fPIC failure in gcc.dg/tree-ssa/pr14841.c
I'm getting a -fpic/-fPIC 4.1/mainline failure in gcc.dg/tree-ssa/pr14841.c on x86_64 and i686: http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00892.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00889.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00891.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00888.html The failures look like this: FAIL: gcc.dg/tree-ssa/pr14841.c scan-tree-dump-times Folded statement: if 1 -- Summary: -fpic/-fPIC failure in gcc.dg/tree-ssa/pr14841.c Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org OtherBugsDependingO 23224 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25444
[Bug middle-end/25441] -fpic/-fPIC failure in gcc.dg/pr23911.c
--- Comment #1 from ghazi at gcc dot gnu dot org 2005-12-16 15:09 --- Forgot to say this is with -fpic or -fPIC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25441
[Bug middle-end/25443] -fpic/-fPIC failure in gcc.dg/tree-ssa/loop-3.c
--- Comment #1 from ghazi at gcc dot gnu dot org 2005-12-16 15:10 --- Forgot to say this is with -fpic or -fPIC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25443
[Bug middle-end/25445] New: -fpic/-fPIC failure in gcc.dg/tree-ssa/wholeprogram-1.c
I'm getting a -fpic/-fPIC 4.1/mainline failure in gcc.dg/tree-ssa/wholeprogram-1.c on x86_64 and i686: http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00892.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00889.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00891.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00888.html The failures look like this: FAIL: gcc.dg/tree-ssa/wholeprogram-1.c scan-tree-dump-not large_function -- Summary: -fpic/-fPIC failure in gcc.dg/tree-ssa/wholeprogram-1.c Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org OtherBugsDependingO 23224 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25445
[Bug middle-end/25446] New: -fpic/-fPIC failure in gcc.dg/vect/vect-ifcvt-9.c
I'm getting a -fpic/-fPIC 4.1/mainline failure in gcc.dg/vect/vect-ifcvt-9.c on x86_64 and i686: http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00892.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00889.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00891.html http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00888.html The failures look like this: FAIL: gcc.dg/vect/vect-ifcvt-9.c scan-tree-dump-times vectorized 1 loops 2 -- Summary: -fpic/-fPIC failure in gcc.dg/vect/vect-ifcvt-9.c Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org OtherBugsDependingO 23224 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25446
[Bug testsuite/25215] -fpic/-fPIC failure in gcc.dg/20050503-1.c
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-12-16 15:20 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01210.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||12/msg01210.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25215
[Bug target/25384] gcc 4.0.2 compile fails on AIX 5.2: target bigtoc not found
--- Comment #2 from tom at tiri dot li 2005-12-16 15:54 --- Yes, without binutils it is working. I set following ulimits to make it compile: ulimit -c unlimited ulimit -d unlimited ulimit -f unlimited ulimit -m unlimited ulimit -s 131072 But one open question: I CAN COMPILE binutils-2.16.1 successfully, but why can't I use them? What is if i need to compile apps, which need binutils ? Thanks for your reply in advance. Thomas. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25384
[Bug c/25447] New: built-in:0: ICE: in pa_scalar_mode_supported_p, at config/pa/pa.c:5932
/home/dave/gcc-4.2/objdir/./gcc/xgcc -B/home/dave/gcc-4.2/objdir/./gcc/ -B/home/ dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hp pa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/include -isys tem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/sys-include -O2 -O2 -g -O2 -DIN _GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold- style-definition -isystem ./include -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/.. /libdecnumber -g0 -finhibit-size-directive -fno-inline-functions -fno-exception s -fno-zero-initialized-in-bss -fno-unit-at-a-time \ -c ../../gcc/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o built-in:0: internal compiler error: in pa_scalar_mode_supported_p, at config/ pa/pa.c:5932 Please submit a full bug report, with preprocessed source if appropriate. Breakpoint 3, pa_scalar_mode_supported_p (mode=SDmode) at ../../gcc/gcc/config/pa/pa.c:5932 5932 gcc_unreachable (); (gdb) bt #0 pa_scalar_mode_supported_p (mode=SDmode) at ../../gcc/gcc/config/pa/pa.c:5932 #1 0x0008f6c4 in c_common_nodes_and_builtins () at ../../gcc/gcc/c-common.c:3108 #2 0x0002f820 in c_init_decl_processing () at ../../gcc/gcc/c-decl.c:2720 #3 0x000c3b50 in c_objc_common_init () at ../../gcc/gcc/c-objc-common.c:128 #4 0x00589fe8 in lang_dependent_init ( name=0xc00461d2 ../../gcc/gcc/crtstuff.c) at ../../gcc/gcc/toplev.c:1842 #5 0x0058a2e0 in do_compile () at ../../gcc/gcc/toplev.c:1947 #6 0x0058a394 in toplev_main (argc=44, argv=0xc004678c) at ../../gcc/gcc/toplev.c:1980 #7 0x000e640c in main (argc=44, argv=0xc004678c) at ../../gcc/gcc/main.c:35 -- Summary: built-in:0: ICE: in pa_scalar_mode_supported_p, at config/pa/pa.c:5932 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25447
[Bug c/25447] built-in:0: ICE: in pa_scalar_mode_supported_p, at config/pa/pa.c:5932
--- Comment #1 from danglin at gcc dot gnu dot org 2005-12-16 16:48 --- Also hpux. -- danglin at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|hppa-unknown-linux-gnu |hppa*-*-* GCC host triplet|hppa-unknown-linux-gnu |hppa*-*-* GCC target triplet|hppa-unknown-linux-gnu |hppa*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25447
[Bug bootstrap/25438] make: *** No rule to make target `bubblestrap'. Stop.
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-16 16:48 --- Reopening since bubblestrap should be there and not just make. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25438
[Bug target/25447] [4.2 Regression] built-in:0: ICE: in pa_scalar_mode_supported_p, at config/pa/pa.c:5932
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-16 17:07 --- Looks like Ben forgot to update the HPPA target files for the new mode. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Component|c |target Ever Confirmed|0 |1 Keywords||build, ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-12-16 17:07:00 date|| Summary|built-in:0: ICE: in |[4.2 Regression] built- |pa_scalar_mode_supported_p, |in:0: ICE: in |at config/pa/pa.c:5932 |pa_scalar_mode_supported_p, ||at config/pa/pa.c:5932 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25447
[Bug target/25448] New: [4.0/4.1/4.2 Regression] Unfounded warnings from the AVR backend
Hello,
when compiling this code:
procedure My_int;
pragma Machine_Attribute (My_int, signal);
pragma Export (C, My_int, __vector_1);
procedure My_int is begin null; end;
with avr-gcc-4.x I get this warning:
demo_ada.adb:9: warning: `demo_ada__my_int' appears to be a misspelled
signal handler
I do not get this warning with gcc-3.4.x.
IMO, this is caused by the misspelled-signames patch
from Theodore A. Roth:
avr.c:
[...]
{
const char *func_name = IDENTIFIER_POINTER (DECL_NAME (*node));
const char *attr = IDENTIFIER_POINTER (name);
/* If the function has the 'signal' or 'interrupt' attribute, test to
make sure that the name of the function is __vector_NN so as to
catch when the user misspells the interrupt vector name. */
if (strncmp (attr, interrupt, strlen (interrupt)) == 0)
{
if (strncmp (func_name, __vector, strlen (__vector)) != 0)
{
warning (0, %qs appears to be a misspelled interrupt handler,
func_name);
[...]
Ted's patch is a bit too C specific, because it assumes that the source
code function name is equal the symbol name.
(__vector_1 = __vector_1)
In Ada, the source code function name (demo_ada__my_int) for interrupts is
translated to__vector_xx with the Pragma Export (..) statement.
Its not possible to define __vector_1 as a source code function name.
--
Summary: [4.0/4.1/4.2 Regression] Unfounded warnings from the AVR
backend
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: berndtrog at yahoo dot com
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25448
[Bug rtl-optimization/24899] [4.1/4.2 Regression] loop.c miscompiles libgnomecanvas
--- Comment #26 from pinskia at gcc dot gnu dot org 2005-12-16 17:13 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
[Bug target/25448] [4.0/4.1/4.2 Regression] Unfounded warnings from the AVR backend
--- Comment #1 from berndtrog at yahoo dot com 2005-12-16 17:13 --- Created an attachment (id=10516) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10516action=view) proposed patch patch to replace DECL_NAME by DECL_ASSEMBLER_NAME -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25448
[Bug java/25429] can't see private static final int CREATE = 1
--- Comment #6 from tromey at gcc dot gnu dot org 2005-12-16 17:21 --- Subject: Bug 25429 Author: tromey Date: Fri Dec 16 17:20:59 2005 New Revision: 108660 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108660 Log: gcc/java: PR java/25429 * parse.y (resolve_expression_name): Don't generate accessor methods for constant fields. libjava: * testsuite/libjava.jacks/jacks.xfail (8.5.2-accessible-static-member-usage-3): Removed. * testsuite/libjava.compile/rh175833.java: New file. * testsuite/libjava.compile/pr25429.java: New file. Added: branches/gcc-4_1-branch/libjava/testsuite/libjava.compile/pr25429.java - copied unchanged from r108608, trunk/libjava/testsuite/libjava.compile/pr25429.java branches/gcc-4_1-branch/libjava/testsuite/libjava.compile/rh175833.java - copied unchanged from r108608, trunk/libjava/testsuite/libjava.compile/rh175833.java Modified: branches/gcc-4_1-branch/gcc/java/ChangeLog branches/gcc-4_1-branch/gcc/java/parse.y branches/gcc-4_1-branch/libjava/ChangeLog branches/gcc-4_1-branch/libjava/testsuite/libjava.jacks/jacks.xfail -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25429
[Bug c/25449] New: [4.0] endless loop in nbench neural net with -ftree-loop-linear
Starting nbench after compiling it with -ftree-loop-linear leads to an endless loop in the 'neural net' benchmark. This is reproducible with gcc-4.0.0 to gcc-4.0.2. I haven't looked at the preprocessed source for now, sorry. -- Summary: [4.0] endless loop in nbench neural net with -ftree- loop-linear Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: RonnyPeine at gmx dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25449
[Bug objc/25450] New: Enums are encoded incorrectly
Take the following enum:
enum a
{
0, 1, 0x7FFFULL
};
it is still encoded as i even though its size is the same as long long.
Trying to fix this the following failures which needs to be fixed:
objc.dg/encode-3.m
objc.dg/type-size-2.m
--
Summary: Enums are encoded incorrectly
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25450
[Bug java/25429] can't see private static final int CREATE = 1
--- Comment #7 from tromey at gcc dot gnu dot org 2005-12-16 17:24 --- Subject: Bug 25429 Author: tromey Date: Fri Dec 16 17:24:42 2005 New Revision: 108661 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108661 Log: gcc/java: PR java/25429 * parse.y (resolve_expression_name): Don't generate accessor methods for constant fields. libjava: * testsuite/libjava.jacks/jacks.xfail (8.5.2-accessible-static-member-usage-3): Removed. * testsuite/libjava.compile/rh175833.java: New file. * testsuite/libjava.compile/pr25429.java: New file. Added: branches/gcc-4_0-branch/libjava/testsuite/libjava.compile/pr25429.java - copied unchanged from r108608, trunk/libjava/testsuite/libjava.compile/pr25429.java branches/gcc-4_0-branch/libjava/testsuite/libjava.compile/rh175833.java - copied unchanged from r108608, trunk/libjava/testsuite/libjava.compile/rh175833.java Modified: branches/gcc-4_0-branch/gcc/java/ChangeLog branches/gcc-4_0-branch/gcc/java/parse.y branches/gcc-4_0-branch/libjava/ChangeLog branches/gcc-4_0-branch/libjava/testsuite/libjava.jacks/jacks.xfail -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25429
[Bug objc/25450] Enums are encoded incorrectly
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-16 17:29 ---
The enum should be
enum a
{
b = 0, c = 1, d =0x7FFFULL
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25450
