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?

[snip]

> 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.

Take care,

Bill