Subject: Re: Intermediate void* casts
To: None <tech-misc@NetBSD.ORG>
From: Bill Studenmund <email@example.com>
Date: 08/10/2003 17:15:43
On Sun, 10 Aug 2003, Martin Husemann wrote:
> Hi folks,
> sorry for the cross-post, please be sure to only reply to tech-misc to
> avoid spreading this flame fest over various mailing lists.
> Since we will switch to gcc3.3.1 soon and already had first problems
> with incorrect code due to alias bugs, I think we should have a kind
> of a mini audit for these. Usually gcc 3.3.1 warns about this kind
> of problems, but it shuts up if an intermediate void* cast is involved.
> So I tried to find dubious casts to pointer types after casts to void*.
Thanks! This will certainly help us.
Though what exactly is an alias bug?
> The latter point needs manual judgement from someone comfortable with that
> area of the source tree. Possible solutions in that case inlcude:
> - just leave the (void*) in place if alias problems are not possible
> according to manual verification. We should not let the compiler stop
> us doing clever things, if we know what we are doing.
> - rewrite the expression completely to avoid the aliases
> I did this with svr_machdep code for sparc*, where the address of a 64bit
> value was casted to a 32bit pointer to access the two halves of the value.
> Easy to replace with shift/mask expressions. Even clearer IMHO and might
> give the compiler better optimization hints.
> This was the case for bswap64 too (which is the problem that triggered
> all this)
I'm not so sure about that. Can/will the compiler notice that you're only
using half of a 64-bit value? Otherwise, by making this change, you're
pulling in more 64-bit using code. For sparc64 that's not bad, since the
registers are 64-bit. But for sparc, 64-bit values won't fit in a
register, and so manipulating them can be cumbersome.
Yes, I realize that if we're talking about a 64-bit value, other bits of
code are having to deal with the difficulties of 64-bit math & such. But
if there's a place where we can make the code more efficient than the
compiler will on its own, I think we should.