Re: [PATCHES] fix for strict-alias warnings
От | Andrew Dunstan |
---|---|
Тема | Re: [PATCHES] fix for strict-alias warnings |
Дата | |
Msg-id | 3F8AC072.2070907@dunslane.net обсуждение исходный текст |
Ответ на | Re: [PATCHES] fix for strict-alias warnings (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: