C99 and C++0x status pages
Yesterday, I spent an hour looking for the C99 and C++0x status pages in http://gcc.gnu.org/, http://gcc.gnu.org/c99status.html http://gcc.gnu.org/projects/cxx0x.html Apparently, the shortest path to the latter is "Releases" -> "GCC 4.5.1" -> "GCC 4.5.1 Jul 31, 2010 (changes)" -> "Improved experimental support for the upcoming C++0x" -> "please see the C++0x in GCC project page" Those are among the most useful pages of the site, it makes no sense to bury them 4+ levels deep. -- André Majorel http://www.teaser.fr/~amajorel/
Re: Add uninitialized attribute?
On 08/30/2010 03:50 PM, Vincent Lefevre wrote: > On 2010-08-30 14:46:57 +0200, Michael Matz wrote: >> int x = x; >> >> is the way GCC offers this idiom since about forever, no need for an >> attribute. Downthread I see that people worry about this generating an >> actual (uninitialized) access to x. They are confused. > > This is not a good idea as "int x = x;" may really generate an > (uninitialized) access to x with other compilers. Absolutely so. I suspect it's even undefined behaviour in the standard language. There's no way that this idiom should appear anywhere in GNU code. Andrew.
Re: C99 and C++0x status pages
Andre Majorel wrote: > Those are among the most useful pages of the site, it makes no > sense to bury them 4+ levels deep. Google is your friend: when asked for g++ c++0x it returns the correct page as the first result. I always use it that way, because website messiness appears to be a de facto Internet standard and GNU is well known for its standard conformance. ;-) Best regards, Piotr
RE: Clustering switch cases
> I will be looking at the patch Rahul posted and will try to see if I > can improve on it. See attached patch (again) that Paulo is referring to. Sending to GCC failed due to email client issues. I have another patch for http://gcc.gnu.org/ml/gcc/2010-08/msg00413.html Which I will send out shortly. Rahul switch_case_clusters.patch Description: switch_case_clusters.patch
Re: Add uninitialized attribute?
On 8/31/2010 1:19 AM, Andrew Haley wrote: > On 08/30/2010 03:50 PM, Vincent Lefevre wrote: >> On 2010-08-30 14:46:57 +0200, Michael Matz wrote: >>> int x = x; >>> >>> is the way GCC offers this idiom since about forever, no need for an >>> attribute. Downthread I see that people worry about this generating an >>> actual (uninitialized) access to x. They are confused. >> >> This is not a good idea as "int x = x;" may really generate an >> (uninitialized) access to x with other compilers. > > Absolutely so. I suspect it's even undefined behaviour in the standard > language. There's no way that this idiom should appear anywhere in > GNU code. I agree; an attribute, or the __unitialized__ keyword would be much cleaner. On the other hand, I think GCC should continue to accept "int x = x;" as a synonym for the forseeable future; whether or not it's good language design it has been a de facto part of GNU C for a long time. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
End of GCC 4.6 Stage 1: October 27, 2010
We (GCC RMs) plan to close GCC 4.6 Stage 1 on or or about October 27, 2010 (the closing day of the GCC Summit). Major features should be checked in prior to this point. Please let us know if you have a major feature that you think you will not be able to get checked in prior to October 27th. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: How is the definition of stack canary on MIPS arch?
On 08/30/2010 08:36 PM, Adam Jiang wrote: On Mon, Aug 30, 2010 at 10:43:44AM -0700, David Daney wrote: On 08/30/2010 09:46 AM, Richard Henderson wrote: On 08/30/2010 03:45 AM, Adam Jiang wrote: When I read the source in Linux kerne, it was said that stack canary for implementing stack protector is defined as an offset to %gs on x86 architecture. How about stack canary defined on MIPS? It's not implemented for MIPS. For the Linux kernel, the MIPS stack canary would be a constant offset (that depends on PAGE_SIZE) from register $28. David Daney Thanks, David and Richard. Is there code, doc or anything on this topic I can refer to? Is it defined in gcc internally or in kernel source itself? Would you please redirect me to the right place? I am unaware of any documents. The MIPS Linux kernel ABI is not really documented anywhere, one learns it by studying and hacking on the source code. 32-bit kernels use a variant of the o32 ABI, 64-bit kernels use a variant of n64. Both dedicate register $28 as a pointer to the thread area of which the stack is a part. The form any stack canary for the MIPS Linux kernel will be determined by whomever implements it. I have done some research by googling. Here are what I've gotten. http://www.trl.ibm.com/projects/security/ssp/main.html http://www.trl.ibm.com/projects/security/ssp/ http://lxr.linux.no/linux+v2.6.35/arch/x86/include/asm/stackprotector.h However, it seems there is no documents about how this is done on MIPS. Do I miss something? At RTH said, "It's not implemented for MIPS.", so there was really nothing to miss. David Daney
gcc-4.4-20100831 is now available
Snapshot gcc-4.4-20100831 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100831/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 163704 You'll find: gcc-4.4-20100831.tar.bz2 Complete GCC (includes all of below) MD5=d4dbb54668eda7795b8771495212e91d SHA1=9ca5123e526e070b611dd1c770156ce66c6cbbd0 gcc-core-4.4-20100831.tar.bz2C front end and core compiler MD5=acb6af2584c839f3d57682ff0acc95ae SHA1=3dfdd4ff3a6cdc8c387cc4cb9ace6bc5e0bf525f gcc-ada-4.4-20100831.tar.bz2 Ada front end and runtime MD5=35bb3a0c17697309dd9836356cb9263e SHA1=3ea7812b48eef0e207f9fa07d1db007ac9ee888d gcc-fortran-4.4-20100831.tar.bz2 Fortran front end and runtime MD5=945699f9818d680c59d784e020541959 SHA1=c3894a19d7ca05fdada77fd97506545f9a02f257 gcc-g++-4.4-20100831.tar.bz2 C++ front end and runtime MD5=af021b5be18edd854122b6e5a8cebf43 SHA1=f2096caa79ab4c572ad1e6ee96698d10aa3fd031 gcc-java-4.4-20100831.tar.bz2Java front end and runtime MD5=9fa798f47c730852fec53dfa4cadafcc SHA1=c78b9acf2b903e09084bd8c943c1020ef53babb6 gcc-objc-4.4-20100831.tar.bz2Objective-C front end and runtime MD5=8a00f268202cbb867a9fa3c0b38f2e3b SHA1=043054c0f8859b188a847910c76b13bad4638a43 gcc-testsuite-4.4-20100831.tar.bz2 The GCC testsuite MD5=c56fa452e043e6e1a1519578dab13af9 SHA1=42e432e95b7ea6a6bccbc436e11e511f210b84a2 Diffs from 4.4-20100824 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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: Clustering switch cases
> > In fact we might want to move switch optimization up to the tree level > > (just because it's way easier to deal with there). Thus, lower switch > > to a mixture of binary tree & jump-tables (possibly using perfect > > hashing). > > Doing the optimisation at the tree-level was exactly my initial idea. > By splitting the switches at the tree-level, before expand_case, would > then allow for expand_case to transform it either to a jump table or > binary tree depending on the situation. I'd kinda hope that doing the optimization at the tree level means expand_case doesn't have to handle both types. The tree code converts sparse case ranges to explicit conditionals (or a switch on a compact perfect hash), so anything left to RTL expansion must be a jump table. Paul
Atom 2010-Q3 SPEC CPU 2K results
H.J. gcc 4.6 Atom 2010-Q3.xlsx Description: gcc 4.6 Atom 2010-Q3.xlsx
Recall: Atom 2010-Q3 SPEC CPU 2K results
Lu, Hongjiu would like to recall the message, "Atom 2010-Q3 SPEC CPU 2K results".
