From owner-freebsd-current Mon Nov 11 10:48:13 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D50437B404 for ; Mon, 11 Nov 2002 10:48:11 -0800 (PST) Received: from dignus.com (sdsl-64-32-254-102.dsl.iad.megapath.net [64.32.254.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9742643E42 for ; Mon, 11 Nov 2002 10:48:10 -0800 (PST) (envelope-from rivers@dignus.com) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.11.6/8.11.3) with ESMTP id gABIaFR16749; Mon, 11 Nov 2002 13:36:15 -0500 (EST) (envelope-from rivers@dignus.com) Received: (from rivers@localhost) by lakes.dignus.com (8.11.6/8.11.3) id gABIgp756047; Mon, 11 Nov 2002 13:42:51 -0500 (EST) (envelope-from rivers) Date: Mon, 11 Nov 2002 13:42:51 -0500 (EST) From: Thomas David Rivers Message-Id: <200211111842.gABIgp756047@lakes.dignus.com> To: brandt@fokus.gmd.de, rivers@dignus.com Subject: Re: gcc 3.2.1 optimization bug ? Cc: FreeBSD-current@FreeBSD.ORG, gallatin@cs.duke.edu In-Reply-To: <20021111193234.E32091-100000@beagle.fokus.gmd.de> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Harti Brandt wrote: > > Yes, of course, but one would assume it to work (I suppose there is a > large amount of code that assumes it will work). Not a safe assumption at all. For example, what if the alignment requirements for `short' and `int' are different (as they frequently are.) Then, dereferencing one type via another type will likely "blow-up". (This is often the case on a SPARC platform when dereferencing `int *' pointers from `char' data.) ANSI requires that a diagnostic be generated in this case, there are some compilers in the world that make this a strict error. > I just tried to give a counter example to your hope, that every sane > compiler would do the right thing with using a union for casting. I would > also assume that every sane compiler would do the right thing for the > above code. The compiler does what it can - but it doesn't mean the code will work. So - the best the compiler can do is say "Hey! You've done something that might not work, but we're going to keep going anyway." > > IMHO, the C-standard is broken with regard to the rules for type > compatibility. As far as I remember these rules came into the standard > from one or two well-known PC compiler vendors that wanted to allow very > aggressive optimisation to show good benchmark results. The 'restrict' > keyword seems to be also an outcome of this. I believe the rules were motivated by two things. The need for optimizations as you point out. Without the "type-punning" rule, a decent optimizer has to assume everything is aliased at every pointer dereference, which denies many nice optimizations. The second is the reality of common hardware in the world (e.g. SPARC) where doing this is quite dangerous. - Dave Rivers - -- rivers@dignus.com Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message