gcc-4.3-20110515 is now available
Snapshot gcc-4.3-20110515 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20110515/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 173775 You'll find: gcc-4.3-20110515.tar.bz2 Complete GCC (includes all of below) MD5=030d71799cb64b168cae217f4a514e1e SHA1=f443e6c686b8be61d6d0a5b25ea9852702d3b8cf gcc-core-4.3-20110515.tar.bz2C front end and core compiler MD5=6037078754014cac95a209626a6ec968 SHA1=96c913662455584e1cb4b70dcac79a94c6da2fc9 gcc-ada-4.3-20110515.tar.bz2 Ada front end and runtime MD5=621832709589e05f8325aa586f40128e SHA1=3dfacdd69aa51b7debf6f726f2ae5035532abfe3 gcc-fortran-4.3-20110515.tar.bz2 Fortran front end and runtime MD5=baa7e1261f1dd4debc9c6eefb76c15e5 SHA1=e681263756385a72a35e13a048a0d408b9074f17 gcc-g++-4.3-20110515.tar.bz2 C++ front end and runtime MD5=2ab28fb9c07a5166fd908af5efa9672e SHA1=3a0d1161bd9bd30b5fe655f2967b4a5f99255af5 gcc-go-4.3-20110515.tar.bz2 Go front end and runtime MD5=6f735456cc145e5abd29e5a51925c57e SHA1=a04d81e9288174c6f014335855056b7502b9295a gcc-java-4.3-20110515.tar.bz2Java front end and runtime MD5=54e02bf6913009f39ee0c3aaeaac2b54 SHA1=30c2058f9d4d1e3579da9b6973a5545975e10bd4 gcc-objc-4.3-20110515.tar.bz2Objective-C front end and runtime MD5=d32d1fb70e1962cb1cabbc740c99c3a0 SHA1=2616375208ca6fc10b62c03213610a668b6deaf0 gcc-testsuite-4.3-20110515.tar.bz2 The GCC testsuite MD5=7d8eb231c0dfbf7204b1c403253ccba9 SHA1=339291f9de97ea3b14408761b4db30df5045bde0 Diffs from 4.3-20110508 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
Re: gcc-4.3-20110515 is now available
On Sun, May 15, 2011 at 07:50:34PM -, gccad...@gcc.gnu.org wrote: > Snapshot gcc-4.3-20110515 is now available on > ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20110515/ > and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. If we're building 4.7 snapshots, do we still need 4.3? -- Daniel Jacobowitz
Improving build on OpenBSD x86_64
A few months ago I managed to build gcc 4.5.1 on an OpenBSD x86_64 platform. This was difficult, even with the patches available in my system's ports tree (which could build gcc 4.3). I would like to volunteer to make this platform better supported. However, I have not contributed to gcc before, and I do not know where to begin. I would like to work with a mentor who can assist me with the gcc community's policies and procedures. Who would help me get started? -- Kyle Markley
Re: Bug detecting AMD K6-2+ with -march=native ?
"Stroller" 写入消息 news:0bead785-392b-49e3-a3d1-0f015b954...@stellar.eclipse.co.uk... Hi there, I have a Sun / Cobalt Qube 3 with an AMD K6-2+ CPU, and gcc seems to be misdetecting it as an Athlon when using -march=native # gcc -v -Q --help=target -march=native 2>&1 | grep march /usr/libexec/gcc/i586-pc-linux-gnu/4.5.2/cc1 -v help-dummy -D_FORTIFY_SOURCE=2 -march=athlon --param l1-cache-size=32 --param l1-cache-line-size=32 --param l2-cache-size=128 -mtune=athlon -dumpbase help-dummy -auxbase help-dummy -version -fhelp=target -o /tmp/ccQrke9q.s -march= athlon # I've tried a couple of different versions of gcc - 4.4.4 and 4.5.2 - but they both show the same. Someone on the linux-cobalt mailing list can also reproduce. When I compile nano using `-march=i586`, `-march=k6-2` or `-march=k6-3` it works fine. If I compile it with `-march=native` then nano crashes on startup saying "illegal instruction". /proc/cpuinfo seems to show the CPU correctly: # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 13 model name : AMD-K6(tm)-III Processor stepping: 4 cpu MHz : 448.140 cache size : 128 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr cx8 pge mmx syscall 3dnowext 3dnow k6_mtrr bogomips: 896.28 clflush size: 32 cache_alignment : 32 address sizes : 32 bits physical, 32 bits virtual power management: ts fid vid # AIUI the K6-2+ is architecturally the same as a K6-3, so I assume this is fine. The family & model above match what wikipedia says it should be for a K6-2+ (although they're also the same for a K6-3+). It's a bug in GCC. Can you try the patch at http://gcc.gnu.org/bugzilla/attachment.cgi?id=24233? -- Zuxy
