"Andrew Dunstan" <[EMAIL PROTECTED]> 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*
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.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.
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
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
