gcc-4.6-20120106 is now available (fwd)
FYI. Somehow these announcements have not been making it to the mailing list for a week or two, so I am forwarding them manually for the time being. Gerald -- Forwarded message -- Snapshot gcc-4.6-20120106 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120106/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 182974 You'll find: gcc-4.6-20120106.tar.bz2 Complete GCC MD5=054f4098036cfd1d12a9c684a3ed766c SHA1=0446510a33a4f9e51aeec0cf3b30a21c59758b19 Diffs from 4.6-20111230 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
gcc-4.7-20120107 is now available
Snapshot gcc-4.7-20120107 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20120107/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 182982 You'll find: gcc-4.7-20120107.tar.bz2 Complete GCC MD5=6030ef35c59015c01227d16b8f964d90 SHA1=331c65df8e74020da7baaec9914d564f60f18de4 Diffs from 4.7-20111231 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 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.
ChangeLog rotation
Shouldn't trunk/gcc/ChangeLog be rotated for the new year? Also, there is a conflict marker introduced in 182938.
FW: gcc uses too much stack?
Have people considered that stack space should be used more conservatively by gcc? More malloc, less alloca, fewer/smaller local variables? More std::stack or such, less recursion on the machine stack? (Yes, I know std::stack has no existing use in gcc yet.) Don't make the amount of stack used dependent on the input? If something can be compiled with N stack, then anything can be? Is a reasonable goal? You know, heap is generally much larger than stack, and easier to detect exhaustion of? Granted, yes, I understand very well, heap is much slower to allocate and requires explicit free, and is subject to fragmentation. Thanks, - Jay > Date: Sun, 8 Jan 2012 00:05:01 -0500 > To: djgpp-digest-da...@delorie.com > > 2012/01/07/15:03:06 ANNOUNCE: DJGPP port of GNU binutils 2.22 uploaded. > > -- > ... > DJGPP specific changes. > === > - This port allows a maximal number of 4294967296 relocations per object > file > and a maximal number of 4294967296 of lines per executable file. > The previous limits were the classical COFF limitations of 65536 for > boths. > Please note, that due to limitations inherent to DOS and memory ressources > not every file can be compiled. E.g.: to be able to compile a single file > containing up to 3 * 65536 relocations I had to increment stack space of > cc1.exe from 2MB to 10MB. If the file contains 4 * 65536 relocations then > cc1.exe aborts because memory has become exhausted. Neither as.exe nor > ld.exe have shown memory issues. Both have the standard stack space of > 512KB. In other words, even if 32 bit values for relocation and line > counters are now supported by DJGPP port of as.exe and ld.exe it does not > imply that large files can be successfully compiled and linked. There are > memory limitations that may not be solvable. ... > > Enjoy. > > Guerrero, Juan Manuel ...
