On 2017-06-05 14:57:10 -0400, Tom Lane wrote: > > If it doesn't prevent both the hardware and the compiler from > > reordering, it's broken. See the comments for pg_read_barrier() in > > atomics.h. > > Meh. Without volatile, I think that the compiler would be within its > rights to elide the nentry local variable and re-fetch toc->toc_nentry > each time through the loop.
I don't think that's true. Excerption from the docs of the macros: About pg_read_barrier() * A read barrier must act as a compiler barrier, and in addition must About pg_compiler_barrier(): * A compiler barrier need not (and preferably should not) emit any actual * machine code, but must act as an optimization fence: the compiler must not * reorder loads or stores to main memory around the barrier. However, the * CPU may still reorder loads or stores at runtime, if the architecture's * memory model permits this. */ Given that I don't see how it'd be permissible to elide the local variable. Are you saying that's permitted, or that our implementations don't guarantee that? - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
