Tom Lane wrote:
>"Andrew Dunstan" <andrew@dunslane.net> writes:
>
>
>>I was inder the impression, perhaps incorrectly, the casting the pointers to
>>(void *) would inhibit the compiler from making any assumptions about what
>>it pointed to, and hence inhibit bad effects from those assumptions. The
>>only way to know would be to examine the assembler output, I suppose. The
>>alternative is that it would merely inhibit the compiler from issuing a
>>warning and mask a bad effect. That would be nasty
>>
>>
>
>IIUC the issue is whether the compiler might incorrectly rearrange the
>order of operations based on the assumption that two pointers point
>to different storage (when in fact they point to the same storage).
>
*nod*
>I don't see what about introducing "(void *)" would be likely to keep
>the compiler from making such assumptions --- you'll still have the same
>two pointers and the exact same sequence of operations. Accordingly,
>I think it's very likely that the so-far-proposed patches are indeed
>masking the symptom and not solving the real problem.
>
>
>
My thinking was that it makes those assumptions based on the type of the
pointer, and it doesn't know the type in the case of (void *).
Otherwise it really ought to omit a warning even when you cast to (void
*), IMNSHO.
You could well be right (as I implied above :-) ), and there are at
least some clues that gcc isn't very smart about this.
So I still think adding -fno-strict-aliasing is the way to go for now.
(back to my day job)
cheers
andrew
