gcc-4.6-20110312 is now available
Snapshot gcc-4.6-20110312 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110312/ 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/trunk revision 170907 You'll find: gcc-4.6-20110312.tar.bz2 Complete GCC (includes all of below) MD5=643f8544caac419bdcfb7bae9e68a619 SHA1=022d63fa7605f173fd7bfd708d0f0a38aaa13683 gcc-core-4.6-20110312.tar.bz2C front end and core compiler MD5=bd1a8a5f00a2e3e52741c40e1bcc76a7 SHA1=2a1721523016efa2052f70749197662516a37345 gcc-ada-4.6-20110312.tar.bz2 Ada front end and runtime MD5=825935b58133392baf9b1655ff89cf51 SHA1=fa8a6e69dd5add0575e68202646b2fadd62a5849 gcc-fortran-4.6-20110312.tar.bz2 Fortran front end and runtime MD5=1044dd65edf528af02c06cd978de4629 SHA1=93a323e835446158a858c952bfcb396d0fdfc131 gcc-g++-4.6-20110312.tar.bz2 C++ front end and runtime MD5=7fe38238357a1c85eabb3987423e4f1d SHA1=650cc9fc8c84ab15ecd51f8064e17278c4de766a gcc-go-4.6-20110312.tar.bz2 Go front end and runtime MD5=e1253e72f0b2e8256155d8f9cbcad6b0 SHA1=2147a48be284c63b3de63c7c047903f4c4994a3c gcc-java-4.6-20110312.tar.bz2Java front end and runtime MD5=fed1c8ca17525217786b46aa907b861a SHA1=65cfbe518ce63a2631b79e82ff29e0c5f787b09a gcc-objc-4.6-20110312.tar.bz2Objective-C front end and runtime MD5=97b6c5ca2b695ede0efd92460af475df SHA1=92f1beb67f7e257d0f52a4db8852c9961e75d80a gcc-testsuite-4.6-20110312.tar.bz2 The GCC testsuite MD5=9b5a69da74465fa9aeabf564ef049b58 SHA1=3fd237a4df73ad25c00a5737e630751b40cd69fe Diffs from 4.6-20110305 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.
darwin LTO broken under Xcode 3.2.6/4.0
With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made to the darwin assembler which effectively breaks LTO support for darwin. The design of LTO on darwin was based on the fact that mach-o object files tolerated additional sections as long as they didin't contain symbols. With Xcode 3.2.6/4.0, the assembler appears to be strictly counting sections and objecting when these exceed 255. This breaks huge sections of the lto testsuite and prevents larger projects like xplor-nih to compile if Xcode 3.2.6/4.0 is installed. I am afraid that unless Apple reverts this change, our only recourse would be to resort to an elf object container for the lto sections within the mach-o files (introducing an undesired dependency on libelf for FSF gcc on darwin). My understanding was that the lto design did not allow the number of sections required in the lto files to be reduced. Jack
Re: darwin LTO broken under Xcode 3.2.6/4.0
Jack Howarth writes: >With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made > to > the darwin assembler which effectively breaks LTO support for darwin. The > design > of LTO on darwin was based on the fact that mach-o object files tolerated > additional > sections as long as they didin't contain symbols. With Xcode 3.2.6/4.0, the > assembler > appears to be strictly counting sections and objecting when these exceed 255. > This > breaks huge sections of the lto testsuite and prevents larger projects like > xplor-nih > to compile if Xcode 3.2.6/4.0 is installed. I am afraid that unless Apple > reverts this > change, our only recourse would be to resort to an elf object container for > the lto > sections within the mach-o files (introducing an undesired dependency on > libelf for > FSF gcc on darwin). My understanding was that the lto design did not allow > the number > of sections required in the lto files to be reduced. We no longer use libelf on any system. This is largely controlled by the simple-object interface. It should be straightforward to change the way that simple-object works with Mach-O without changing the simple-object interface to the rest of gcc. Then we could change the gcc output to, e.g., put all the information in a single Mach-O section. I suppose we should first ask Apple why they made the change and whether it was intentional. Ian
Re: darwin LTO broken under Xcode 3.2.6/4.0
On Mar 12, 2011, at 8:17 PM, Jack Howarth wrote: > With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made to > the darwin assembler which effectively breaks LTO support for darwin. The > design > of LTO on darwin was based on the fact that mach-o object files tolerated > additional > sections as long as they didin't contain symbols. With Xcode 3.2.6/4.0, the > assembler > appears to be strictly counting sections and objecting when these exceed 255. > This > breaks huge sections of the lto testsuite and prevents larger projects like > xplor-nih > to compile if Xcode 3.2.6/4.0 is installed. I am afraid that unless Apple > reverts this > change, our only recourse would be to resort to an elf object container for > the lto > sections within the mach-o files (introducing an undesired dependency on > libelf for > FSF gcc on darwin). My understanding was that the lto design did not allow > the number > of sections required in the lto files to be reduced. Hi Jack, Please file a bug against the apple bug tracker explaining exactly what you need to work with some example .o files. -Chris
Re: darwin LTO broken under Xcode 3.2.6/4.0
On Sat, Mar 12, 2011 at 09:34:01PM -0800, Chris Lattner wrote: > > On Mar 12, 2011, at 8:17 PM, Jack Howarth wrote: > > > With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made > > to > > the darwin assembler which effectively breaks LTO support for darwin. The > > design > > of LTO on darwin was based on the fact that mach-o object files tolerated > > additional > > sections as long as they didin't contain symbols. With Xcode 3.2.6/4.0, the > > assembler > > appears to be strictly counting sections and objecting when these exceed > > 255. This > > breaks huge sections of the lto testsuite and prevents larger projects like > > xplor-nih > > to compile if Xcode 3.2.6/4.0 is installed. I am afraid that unless Apple > > reverts this > > change, our only recourse would be to resort to an elf object container for > > the lto > > sections within the mach-o files (introducing an undesired dependency on > > libelf for > > FSF gcc on darwin). My understanding was that the lto design did not allow > > the number > > of sections required in the lto files to be reduced. > > Hi Jack, > > Please file a bug against the apple bug tracker explaining exactly what you > need to work with some example .o files. > > -Chris Chris, I have already opened Problem ID: 9126174 on radar and uploaded the builtin-attr-1.s assembly file from the failed... /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20110311/gcc/testsuite/gcc.dg/torture/builtin-attr-1.c -O2 -flto -flto-partition=none -ffast-math -lm --save-temps -v -m32 -o builtin-attr-1.exe linkage. The failure occurs as... builtin-attr-1.s:12528:FATAL:too many sections (maximum 255) when 'as -arch i386 -force_cpusubtype_ALL -o builtin-attr-1.o builtin-attr-1.s' is executed. This same assembly file works fine with 'as' from Xcode 3.2.5. Also the 12528th line happens to be just after the 253rd GNU_LTO section which makes sense as there is a __TEXT,__text_startup and __TEXT,__eh_frame section as well. If I truncate the assembly file at 253 GNU_LTO sections it is assembled without complaint. Nick believed that the assembler was looking for symbols in each section and verifying the section count that way. I don't believe that is true and that a simple count of all sections is being done instead. If true, it prohibits us from using the current approach of placing all of the GNU_LTO sections at the end of the assembly. Since they don't contain symbols this has never been a problem in the past. Jack
