Re: updated code size comparison
On 12/16/2009 03:21 AM, John Regehr wrote: Hopefully the results are more fair and useful now. Again, feedback is appreciated. I would also avoid testcases using volatile. Smaller code on these testcases is often a sign of miscompilation rather than optimization. For example, http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/076389.c is miscompiled on GCC 3.4 and SunCC 5.10. Sorry for not noticing yesterday. Paolo
Please update GNU GCC mirror list
Some of the sites listed on the mirror list http://gcc.gnu.org/mirrors.html aren't up to date and some aren't accessible. LaffeyComputer.com doesn't allow access, and used to require a password for access. This isn't the way a GNU mirror site ought to operate. There should be free public access. John Tellefson Salina, KS USA -- http://www.mozilla.org Firefox browser, Thunderbird email, Seamonkey all-in-one, Sunbird calendar and more. Free open-source software for Windows, Linux, Mac OS and other systems
Re: updated code size comparison
Moreover, aggregating those boolean results to yield things like "X generated larger code than Y NN% of the time" seems even weirder. Is this really useful information, other than for marketing? Hi Miles- Did you click through to one of the pages that shows a rank-ordered list of functions where one compiler generates bigger code than another? Those are the pages that are supposed to contain useful information. You're right, the aggregated results are not useful other than to get a broad overview. John Regehr
GMP and GCC 4.3.2
Dear all, Found on http://gmplib.org/. "N.B. gcc 4.3.2 miscompiles GMP 4.3.x on 64-bit machines. The problem is specific to that very release; specifically gcc 4.3.1 and 4.3.3 seem to work fine." Since porting to a newer version is difficult for me right now, I was wondering if anybody worked on a patch for this specific problem. Thanks, Jc
Re: GMP and GCC 4.3.2
On Wed, Dec 16, 2009 at 7:50 PM, Jean Christophe Beyler wrote: > Dear all, > > Found on http://gmplib.org/. > > "N.B. gcc 4.3.2 miscompiles GMP 4.3.x on 64-bit machines. The problem > is specific to that very release; specifically gcc 4.3.1 and 4.3.3 > seem to work fine." > > Since porting to a newer version is difficult for me right now, I was > wondering if anybody worked on a patch for this specific problem. It has been fixed for 4.3.3. You can search bugzilla to find the offending patch. Richard. > Thanks, > Jc >
Re: GMP and GCC 4.3.2
I've actually searched but still can't find any mention of such bugs/patches. If anybody remembers a key word I could use, that would help. I've tried "4.3.2" or "GMP" but haven't found anything. Thanks a lot, Jc On Wed, Dec 16, 2009 at 2:37 PM, Richard Guenther wrote: > On Wed, Dec 16, 2009 at 7:50 PM, Jean Christophe Beyler > wrote: >> Dear all, >> >> Found on http://gmplib.org/. >> >> "N.B. gcc 4.3.2 miscompiles GMP 4.3.x on 64-bit machines. The problem >> is specific to that very release; specifically gcc 4.3.1 and 4.3.3 >> seem to work fine." >> >> Since porting to a newer version is difficult for me right now, I was >> wondering if anybody worked on a patch for this specific problem. > > It has been fixed for 4.3.3. You can search bugzilla to find the > offending patch. > > Richard. > >> Thanks, >> Jc >> >
Re: GMP and GCC 4.3.2
On Wed, Dec 16, 2009 at 9:54 PM, Jean Christophe Beyler wrote: > I've actually searched but still can't find any mention of such bugs/patches. > > If anybody remembers a key word I could use, that would help. I've > tried "4.3.2" or "GMP" but haven't found anything. I have tried a search on bugs with "Known to fail: 4.3.2" and "Known to work: 4.3.1 and 4.3.2". This gives no result either, so if something was fixed then the target milestones aren't set correctly. A Google search directs me to http://www.mail-archive.com/debian-...@lists.debian.org/msg32172.html and from there to http://gcc.gnu.org/PR36765. But that doesn't look like the right bug. A search on all bugs (open and closed) in GCC bugzilla also gives no useful results. It looks like this was never even filed in GCC bugzilla...? Ciao! Steven > Thanks a lot, > Jc > > On Wed, Dec 16, 2009 at 2:37 PM, Richard Guenther > wrote: >> On Wed, Dec 16, 2009 at 7:50 PM, Jean Christophe Beyler >> wrote: >>> Dear all, >>> >>> Found on http://gmplib.org/. >>> >>> "N.B. gcc 4.3.2 miscompiles GMP 4.3.x on 64-bit machines. The problem >>> is specific to that very release; specifically gcc 4.3.1 and 4.3.3 >>> seem to work fine." >>> >>> Since porting to a newer version is difficult for me right now, I was >>> wondering if anybody worked on a patch for this specific problem. >> >> It has been fixed for 4.3.3. You can search bugzilla to find the >> offending patch. >> >> Richard. >> >>> Thanks, >>> Jc >>> >> >
[034/151] x86: Prevent GCC 4.4.x (pentium-mmx et al) function prologue wreckage
2.6.32-stable review patch. If anyone has any objections, please let us know. -- From: Thomas Gleixner commit 746357d6a526d6da9d89a2ec645b28406e959c2e upstream. When the kernel is compiled with -pg for tracing GCC 4.4.x inserts stack alignment of a function _before_ the mcount prologue if the -march=pentium-mmx is set and -mtune=generic is not set. This breaks the assumption of the function graph tracer which expects that the mcount prologue push %ebp mov %esp, %ebp is the first stack operation in a function because it needs to modify the function return address on the stack to trap into the tracer before returning to the real caller. The generated code is: push %edi lea0x8(%esp),%edi and$0xfff0,%esp pushl -0x4(%edi) push %ebp mov%esp,%ebp so the tracer modifies the copy of the return address which is stored after the stack alignment and therefor does not trap the return which in turn breaks the call chain logic of the tracer and leads to a kernel panic. Aside of the fact that the generated code is horrible for no good reason other -march -mtune options generate the expected: push %ebp mov%esp,%ebp and$0xfff0,%esp which does the same and keeps everything intact. After some experimenting we found out that this problem is restricted to gcc4.4.x and to the following -march settings: i586, pentium, pentium-mmx, k6, k6-2, k6-3, winchip-c6, winchip2, c3, geode By adding -mtune=generic the code generator produces always the expected code. So forcing -mtune=generic when CONFIG_FUNCTION_GRAPH_TRACER=y is not pretty, but at the moment the only way to prevent that the kernel trips over gcc-shrooms induced code madness. Most distro kernels have CONFIG_X86_GENERIC=y anyway which forces -mtune=generic as well so it will not impact those. 2.6.32-stable review patch. If anyone has any objections, please let us know. -- Signed-off-by: Thomas Gleixner LKML-Reference: Cc: Linus Torvalds Cc: Andrew Morton Cc: Ingo Molnar Cc: Peter Zijlstra Cc: H. Peter Anvin Cc: Steven Rostedt Cc: Frederic Weisbecker , Cc: Jeff Law Cc: gcc@gcc.gnu.org Cc: David Daney Cc: Andrew Haley Cc: Richard Guenther Signed-off-by: Greg Kroah-Hartman --- arch/x86/Makefile_32.cpu |6 ++ 1 file changed, 6 insertions(+) --- a/arch/x86/Makefile_32.cpu +++ b/arch/x86/Makefile_32.cpu @@ -46,6 +46,12 @@ cflags-$(CONFIG_MGEODEGX1) += -march=pen # cpu entries cflags-$(CONFIG_X86_GENERIC) += $(call tune,generic,$(call tune,i686)) +# Work around the pentium-mmx code generator madness of gcc4.4.x which +# does stack alignment by generating horrible code _before_ the mcount +# prologue (push %ebp, mov %esp, %ebp) which breaks the function graph +# tracer assumptions +cflags-$(CONFIG_FUNCTION_GRAPH_TRACER) += $(call cc-option,-mtune=generic) + # Bug fix for binutils: this option is required in order to keep # binutils from generating NOPL instructions against our will. ifneq ($(CONFIG_X86_P6_NOP),y)
Successful make profiledbootstrap of GCC 4.4.2 on Snow Leopard 10.6.2 x86_64-apple-darwin10.2.0
This is to report a successful build of GCC 4.4.2 on my laptop. ./config.guess: i386-apple-darwin10.2.0 gcc -v: Using built-in specs. Target: x86_64-apple-darwin10.2.0 Configured with: ../gcc-4.4.2/configure --prefix=/Users/*/Documents/MyApps/Commands/GCC/MacOSX --with-pkgversion="GNU GCC 4.4.2 Codename Lord of Compilers built Dec. 14, 2009 with GMP 4.3.1, MPFR 2.4.2, MPC 0.8.1 and Libelf 0.8.13, bootstrapped by GCC 4.4.2 Codename Optimised Bootstrapper " --with-libelf=/Users//Documents/MyApps/Commands/GCC/Dependencies//libelf-0.8.13 --enable-lto --with-mpc=/Users/*/Documents/MyApps/Commands/GCC/Dependencies//mpc-0.8.1 --with-mpfr=/Users/*/Documents/MyApps/Commands/GCC/Dependencies//mpfr-2.4.2 --with-gmp=/Users/*/Documents/MyApps/Commands/GCC/Dependencies//gmp-4.3.1 --enable-shared --enable-static --target=x86_64-apple-darwin10.2.0 --build=x86_64-apple-darwin10.2.0 --host=x86_64-apple-darwin10.2.0 --enable-threads --enable-languages=c,c++,fortran,objc,obj-c++ --enable-werror --enable-gather-detailed-mem-stats --with-tune=core2 Thread model: posix gcc version 4.4.2 (GNU GCC 4.4.2 Codename Lord of Compilers built Dec. 14, 2009 with GMP 4.3.1, MPFR 2.4.2, MPC 0.8.1 and Libelf 0.8.13, bootstrapped by GCC 4.4.2 Codename Optimised Bootstrapper) Timings of build (was built with profiledbootstrap-built GCC 4.4.2 compiled only with C, environnement variables CC="gcc -g -O3 -fno-omit-frame-pointer"): time make profiledbootstrap ... real 339m16.074s user 93m54.877s sys 13m30.623s NB: There was a 4-hour (240 minutes) period during which the computer was asleep and did not contribute any CPU cycles. The build time was indeed closer to "user" than "real" - about 100 minutes or so. Other relevant information: uname -a: Darwin *-**-MacBook.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov 3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386 System Specs: MacBook6,1 (Late 2009) Standard Configuration Mac OS X 10.6.2 Intel Core 2 Duo 2.26 GHz 2GB DDR3 1066 MHz RAM Xcode 3.2.1 (GCC 4.2.1 (1), Apple Inc.) Bootstrap options: I built a special GCC 4.4.2 from source with Xcode's default gcc 4.2.1 and all optimisation to maximum (CC="gcc -g -O3 -fno-omit-frame-pointer") and time make profiledbootstrap called Optimised Bootstrapper . I then used the same options to build this full version of GCC 4.4.2 and again issued time make profiledbootstrap. The timings may not be fair because of optimisation and the use of a highly optimised bootstrap gcc build, but the timings are provided above. Optimised Bootstrapper took just under an hour to build, with no native language support and only the C compiler (because that's the only thing needed for bootstrapping GCC). Request for update to system-specific installation instructions: I am on Mac OS X Snow Leopard. There has been some noise around the forums that GCC fails for various reasons. It turns out that despite having all the requirements to run 64-bit systems, including a 64-bit processor (an Intel Core 2 Duo), no Macs boot the 64-bit kernel by default and only 4 (These being Mac Pros, Xserves, Macbook Pros and iMacs) are allowed to boot it at all, leaving that the system kernel runs 32-bit, but almost every application is 64-bit. Also, the command uname returns i386 despite the Core 2 Duo being more of a i686 or x86_64, a 64-bit processor. It seems therefore that config.guess confuses itself in bitness, picking the 32-bit version called i386 rather than the correct choice, x86_64. So the recommendation is to add an entry under Build Stats saying that 4.4.2 under x86_64-apple-darwin10.2.0 is successful, and to add to the system-specific installation notes to add these options to the configure: --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --with-tune=[core2 | generic | i686] This essentially forces configure to choose the 64-bit flavour. I selected core2 because I am not compiling executables for any other processors - Macs have all switched to either Core 2 Duo, Core 2 Quad or, in high-ends, to Intel Xeon, Nehalem architecture.
