Re: ANSI-strict pointer aliasing rules

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ANSI-strict pointer aliasing rules
Дата
Msg-id 1920.1146096801@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ANSI-strict pointer aliasing rules  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: ANSI-strict pointer aliasing rules  (Greg Stark <gsstark@mit.edu>)
Re: ANSI-strict pointer aliasing rules  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> In the grandparent's case I think
> the compiler is being really stupid because it can know the two
> pointers are the same. But I'm sure there are more subtle cases where
> it won't know. PostgreSQL typecasts pointers fairly freely.

Actually, if xlc is behaving as Taral says then I'm pretty convinced
it's *broken*; it is assuming far more than is allowed even by the ANSI
aliasing rules.  As I read the spec, ANSI aliasing says that a given
value must always be accessed through equivalent (up to signedness)
primitive types, ie, if you store through an int pointer and fetch
through a long pointer the compiler is allowed to reorder those two
references.  In the example Taral gives, both field references are to
fields of type NodeTag.  I don't see anything in the spec that allows
the compiler to assume they are distinct variables just because they are
members of different struct types.  The spec restriction is defined in
terms of the lvalue type of the particular store or fetch access, not on
what kind of structure it's part of.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Catalog Access (was: [GENERAL] Concurrency problem
Следующее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: GIN - Generalized Inverted iNdex. Try 2.