From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1QcTW2-0005CL-DZ for garchives@archives.gentoo.org; Fri, 01 Jul 2011 02:31:34 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9EB7D1C039; Fri, 1 Jul 2011 02:30:21 +0000 (UTC) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by pigeon.gentoo.org (Postfix) with ESMTP id 631E81C039 for ; Fri, 1 Jul 2011 02:30:21 +0000 (UTC) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=US-ASCII Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LNM00B66UYK9RB0@mta-2.ms.rz.RWTH-Aachen.de> for gentoo-amd64@lists.gentoo.org; Fri, 01 Jul 2011 04:30:20 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.65,455,1304287200"; d="scan'208";a="122126202" Received: from relay-2.ms.rz.rwth-aachen.de (HELO relay.rwth-aachen.de) ([134.130.7.75]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 01 Jul 2011 04:30:20 +0200 Received: from lxtc226.physik.rwth-aachen.de (lxtc226.physik.RWTH-Aachen.DE [134.61.11.80]) by relay.rwth-aachen.de (8.14.4+Sun/8.13.8/1) with ESMTP id p612UKMp018982 for ; Fri, 01 Jul 2011 04:30:20 +0200 (CEST) Received: by lxtc226.physik.rwth-aachen.de (Postfix, from userid 3205) id 613E84E563; Fri, 01 Jul 2011 04:30:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lxtc226.physik.rwth-aachen.de (Postfix) with ESMTP id 40BEF4E3E1 for ; Fri, 01 Jul 2011 04:30:20 +0200 (CEST) Date: Fri, 01 Jul 2011 04:30:20 +0200 (CEST) From: Ian McCulloch To: "gentoo-amd64@lists.gentoo.org" Subject: Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems Message-id: X-Archives-Salt: X-Archives-Hash: 1d125f112b08ac804d6c5f6cfaa32e36 On Fri, 1 Jul 2011, Frank Peters wrote: > On Fri, 1 Jul 2011 00:58:46 +0000 (UTC) Duncan <1i5t5.duncan@cox.net> > wrote: > > > > > I had wondered if this might be an "undefined behavior" optimization > > bug, > > > > Well, the amd64 users list may not be the appropriate place to discuss C > programming, but the problem here stems from attempting to do things > with C that are not supposed to be done with C. Such things are aptly > called "tricks" because they stray away from the convention. I don't think that is true - C has ALWAYS had rules on strict aliasing, even from the first attempts at standardization. Unfortunately it is only recently that common compilers and hardware have really taken advantage of the way the language works to give better optimizing performance by storing more variables in registers rather than reloading pointers from memory every time. Mostly this is due to the small number of registers in the x86 architecture, doesn't lend itself to these optimisations as well as other architectures. Contrast with Itanium for example with lots of registers, some of which are designed to be preserved across a function call. FORTRAN compilers have taken advantage of aliasing optimizations right from the beginning (ie, since the 1960's!), and commodity C compilers are only now just catching up! So these are hardly new optimizations. > > Ideally, I suppose, for these purposes would be to use assembly language > routines mixed into the C code. But this is not as easy as with the > "tricks." Not at all, it is about producing more efficient assembly, using the language rules that have existed practically forever. If programmers have become accustomed to violating those rules, then they'll just have to get accustomed to not violating them. The rules aren't hard! And if you DO want to alias pointers of different types, then there are well-defined ways of doing that, and the resulting code tends to be much more readable too. Regards, Ian