Date: Mon, 11 Nov 2002 13:42:51 -0500 (EST) From: Thomas David Rivers <rivers@dignus.com> To: brandt@fokus.gmd.de, rivers@dignus.com Cc: FreeBSD-current@FreeBSD.ORG, gallatin@cs.duke.edu Subject: Re: gcc 3.2.1 optimization bug ? Message-ID: <200211111842.gABIgp756047@lakes.dignus.com> In-Reply-To: <20021111193234.E32091-100000@beagle.fokus.gmd.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Harti Brandt <brandt@fokus.gmd.de> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211111842.gABIgp756047>