[Bug tree-optimization/32653] [4.3 Regression] Bootstrap failure with excessive memory consumption in tree-ssa-pre compiling libjava/interperter.c
--- Comment #6 from daney at gcc dot gnu dot org 2007-11-05 17:34 --- As of r129803, I can bootstrap c,c++,java on my mipsel-linux build machine with 128MB RAM again. Although some files require more than 128MB of virtual memory, I have plenty of swap and the system does not thrash so horribly that it cannot complete a bootstrap. Unless there are protests, I will mark the bug as FIXED in a couple of days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32653 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#211586: It is not the voice that commands the story: it is the ear.
Elloelloello :) It takes two to destroy a marriage. A hurtful act is the transference to others of the degradation which we bear in ourselves. I know the joy of fishes in the river through my own joy, as I go walking along the same river. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#449433: Should a package supply libgfortran.so and libgfortranbegin.a in /usr/lib?
Package: gfortran-4.2 Version: 4.2.2-3 Severity: minor Hi Matthias et al., Prompted by a couple emails [1] to the ROOT devel list, I'm curious as to why no package in Sid seems to provide a libgfortran.so symlink [without the soversion] nor libgfortranbegin.a directly in /usr/lib. This makes it difficult to link a program with the main routine written in FORTRAN using g++ or gcc as the driver for ld. Currently one needs to add -L/usr/lib/gcc/i486-linux-gnu/4.2 to the linking command before supplying -lgfortran -lgfortranbegin . [1] I'll supply a link to the thread when it becomes available on the web archive of roottalk. Is this an oversight, or a deliberate design decision? Not knowing which, I couldn't decide on the severity of this bug, so I set it to "minor". In Etch there was a libgfortran1-dev package that did supply these files (and was depended upon by gfortran-4.1), but nothing equivalent exists in Sid. thanks and best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#123468: There's no glory like those who save their country.
And a very good morning to you! :) When you laugh, be sure to laugh at what people do and not at what people are. You should never name an animal which is not yours to keep, or which you intend to eat. With just enough of learning to misquote. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug tree-optimization/33826] [4.1/4.2/4.3 Regression] GCC generates wrong code for infinitely recursive functions
--- Comment #2 from steven at gcc dot gnu dot org 2007-11-05 21:38 --- It seems to me that a recursive function can never be safely treated as const/pure. In fact, any function in an SCC in the call graph could result in an endless loop and is therefore not const/pure. I'm assuming here that hanging in an infinite loop is a "side-effect", and I understand this is a debatable assumption. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||zadeck at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33826 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 443234 to libstdc++6-4.2-dev
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.9.26 > #affects 4.2 as well, see > http://buildd.debian.org/fetch.cgi?pkg=kawari8;ver=8.2.4-3;arch=mips;stamp=1193877367 > reassign 443234 libstdc++6-4.2-dev 4.2.2-3 Bug#443234: Inconsistent definition of _GLIBCXX_USE_C99 across arches Bug reassigned from package `libstdc++6-4.1-dev' to `libstdc++6-4.2-dev'. > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug tree-optimization/33826] [4.1/4.2/4.3 Regression] GCC generates wrong code for infinitely recursive functions
--- Comment #3 from zadeck at naturalbridge dot com 2007-11-05 22:16 --- Subject: Re: [4.1/4.2/4.3 Regression] GCC generates wrong code for infinitely recursive functions steven at gcc dot gnu dot org wrote: > --- Comment #2 from steven at gcc dot gnu dot org 2007-11-05 21:38 > --- > It seems to me that a recursive function can never be safely treated as > const/pure. In fact, any function in an SCC in the call graph could result in > an endless loop and is therefore not const/pure. I'm assuming here that > hanging > in an infinite loop is a "side-effect", and I understand this is a debatable > assumption. > > > I have never been happy with how the "edge" cases of programs that are designed to do undefined behavior are used to define what is correct and what is not correct for well defined programs. So i am unconvinced by steven's argument. If someone either can turn this into a program that gets the wrong answer on a program that has a defined behavior with a language that gcc supports, then i will take this bug seriously. Kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33826 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug tree-optimization/33826] [4.1/4.2/4.3 Regression] GCC generates wrong code for infinitely recursive functions
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-11-05 23:06 --- > If someone either can turn this into a program that gets the wrong > answer on a program that has a defined behavior with a language that gcc > supports, then i will take this bug seriously. There is already an Ada testcase in the report; if compiled in full conformance mode (with -fstack-check), it should exhaust the stack and raise Storage_Error on the x86. Of course this should not have P1 priority. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33826 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#449433: roottalk links
I wrote: > Prompted by a couple emails [1] to the ROOT devel list, I'm curious as > to why no package in Sid seems to provide a libgfortran.so symlink > [without the soversion] nor libgfortranbegin.a directly in /usr/lib. > This makes it difficult to link a program with the main routine written > in FORTRAN using g++ or gcc as the driver for ld. Currently one needs > to add -L/usr/lib/gcc/i486-linux-gnu/4.2 to the linking command before > supplying -lgfortran -lgfortranbegin . > > [1] I'll supply a link to the thread when it becomes available on the > web archive of roottalk. And here are the promised links to the relevant threads: http://root.cern.ch/root/roottalk/roottalk07/1147.html http://root.cern.ch/root/roottalk/roottalk07/1150.html In the meantime, ROOT upstream has decided in svn trunk [2] to utilize gfortran -print-file-name=libgfortran.so gfortran -print-file-name=libgfortranbegin.a to get the paths to gfortran libraries, which I've verified should do The Right Thing (TM) on a Sid system. So this bug is now more academic (at least from the point of view of ROOT) than a real problem -- feel free to close if you wish, or not. [2] http://root.cern.ch/viewcvs/trunk/config/Makefile.linux?r1=20172&r2=20658 best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
