pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix generic read and write barriers for Clang. 7+ messages / 1 participants [nested] [flat]
* pgsql: Fix generic read and write barriers for Clang. @ 2025-11-07 23:39 Thomas Munro <tmunro@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Thomas Munro @ 2025-11-07 23:39 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix generic read and write barriers for Clang. generic-gcc.h maps our read and write barriers to C11 acquire and release fences using compiler builtins, for platforms where we don't have our own hand-rolled assembler. This is apparently enough for GCC, but the C11 memory model is only defined in terms of atomic accesses, and our barriers for non-atomic, non-volatile accesses were not always respected under Clang's stricter interpretation of the standard. This explains the occasional breakage observed on new RISC-V + Clang animal greenfly in lock-free PgAioHandle manipulation code containing a repeating pattern of loads and read barriers. The problem can also be observed in code generated for MIPS and LoongAarch, though we aren't currently testing those with Clang, and on x86, though we use our own assembler there. The scariest aspect is that we use the generic version on very common ARM systems, but it doesn't seem to reorder the relevant code there (or we'd have debugged this long ago). Fix by inserting an explicit compiler barrier. It expands to an empty assembler block declared to have memory side-effects, so registers are flushed and reordering is prevented. In those respects this is like the architecture-specific assembler versions, but the compiler is still in charge of generating the appropriate fence instruction. Done for write barriers on principle, though concrete problems have only been observed with read barriers. Reported-by: Alexander Lakhin <exclusion@gmail.com> Tested-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/d79691be-22bd-457d-9d90-18033b78c40a%40gmail.com Backpatch-through: 13 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/c5d34f4a550f26583a0b92e294eff7d001e318d3 Modified Files -------------- src/include/port/atomics/generic-gcc.h | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix generic read and write barriers for Clang. @ 2025-11-07 23:39 Thomas Munro <tmunro@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Thomas Munro @ 2025-11-07 23:39 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix generic read and write barriers for Clang. generic-gcc.h maps our read and write barriers to C11 acquire and release fences using compiler builtins, for platforms where we don't have our own hand-rolled assembler. This is apparently enough for GCC, but the C11 memory model is only defined in terms of atomic accesses, and our barriers for non-atomic, non-volatile accesses were not always respected under Clang's stricter interpretation of the standard. This explains the occasional breakage observed on new RISC-V + Clang animal greenfly in lock-free PgAioHandle manipulation code containing a repeating pattern of loads and read barriers. The problem can also be observed in code generated for MIPS and LoongAarch, though we aren't currently testing those with Clang, and on x86, though we use our own assembler there. The scariest aspect is that we use the generic version on very common ARM systems, but it doesn't seem to reorder the relevant code there (or we'd have debugged this long ago). Fix by inserting an explicit compiler barrier. It expands to an empty assembler block declared to have memory side-effects, so registers are flushed and reordering is prevented. In those respects this is like the architecture-specific assembler versions, but the compiler is still in charge of generating the appropriate fence instruction. Done for write barriers on principle, though concrete problems have only been observed with read barriers. Reported-by: Alexander Lakhin <exclusion@gmail.com> Tested-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/d79691be-22bd-457d-9d90-18033b78c40a%40gmail.com Backpatch-through: 13 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f8ccab0e9701117a80385bf134ad2ce5c1dc68e8 Modified Files -------------- src/include/port/atomics/generic-gcc.h | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix generic read and write barriers for Clang. @ 2025-11-07 23:39 Thomas Munro <tmunro@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Thomas Munro @ 2025-11-07 23:39 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix generic read and write barriers for Clang. generic-gcc.h maps our read and write barriers to C11 acquire and release fences using compiler builtins, for platforms where we don't have our own hand-rolled assembler. This is apparently enough for GCC, but the C11 memory model is only defined in terms of atomic accesses, and our barriers for non-atomic, non-volatile accesses were not always respected under Clang's stricter interpretation of the standard. This explains the occasional breakage observed on new RISC-V + Clang animal greenfly in lock-free PgAioHandle manipulation code containing a repeating pattern of loads and read barriers. The problem can also be observed in code generated for MIPS and LoongAarch, though we aren't currently testing those with Clang, and on x86, though we use our own assembler there. The scariest aspect is that we use the generic version on very common ARM systems, but it doesn't seem to reorder the relevant code there (or we'd have debugged this long ago). Fix by inserting an explicit compiler barrier. It expands to an empty assembler block declared to have memory side-effects, so registers are flushed and reordering is prevented. In those respects this is like the architecture-specific assembler versions, but the compiler is still in charge of generating the appropriate fence instruction. Done for write barriers on principle, though concrete problems have only been observed with read barriers. Reported-by: Alexander Lakhin <exclusion@gmail.com> Tested-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/d79691be-22bd-457d-9d90-18033b78c40a%40gmail.com Backpatch-through: 13 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/03d9140cbd00caf946c59e154ebb3af651a27306 Modified Files -------------- src/include/port/atomics/generic-gcc.h | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix generic read and write barriers for Clang. @ 2025-11-07 23:40 Thomas Munro <tmunro@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Thomas Munro @ 2025-11-07 23:40 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix generic read and write barriers for Clang. generic-gcc.h maps our read and write barriers to C11 acquire and release fences using compiler builtins, for platforms where we don't have our own hand-rolled assembler. This is apparently enough for GCC, but the C11 memory model is only defined in terms of atomic accesses, and our barriers for non-atomic, non-volatile accesses were not always respected under Clang's stricter interpretation of the standard. This explains the occasional breakage observed on new RISC-V + Clang animal greenfly in lock-free PgAioHandle manipulation code containing a repeating pattern of loads and read barriers. The problem can also be observed in code generated for MIPS and LoongAarch, though we aren't currently testing those with Clang, and on x86, though we use our own assembler there. The scariest aspect is that we use the generic version on very common ARM systems, but it doesn't seem to reorder the relevant code there (or we'd have debugged this long ago). Fix by inserting an explicit compiler barrier. It expands to an empty assembler block declared to have memory side-effects, so registers are flushed and reordering is prevented. In those respects this is like the architecture-specific assembler versions, but the compiler is still in charge of generating the appropriate fence instruction. Done for write barriers on principle, though concrete problems have only been observed with read barriers. Reported-by: Alexander Lakhin <exclusion@gmail.com> Tested-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/d79691be-22bd-457d-9d90-18033b78c40a%40gmail.com Backpatch-through: 13 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/2f76ffe5e4721302dde68a4be4eae974a673864c Modified Files -------------- src/include/port/atomics/generic-gcc.h | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix generic read and write barriers for Clang. @ 2025-11-07 23:40 Thomas Munro <tmunro@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Thomas Munro @ 2025-11-07 23:40 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix generic read and write barriers for Clang. generic-gcc.h maps our read and write barriers to C11 acquire and release fences using compiler builtins, for platforms where we don't have our own hand-rolled assembler. This is apparently enough for GCC, but the C11 memory model is only defined in terms of atomic accesses, and our barriers for non-atomic, non-volatile accesses were not always respected under Clang's stricter interpretation of the standard. This explains the occasional breakage observed on new RISC-V + Clang animal greenfly in lock-free PgAioHandle manipulation code containing a repeating pattern of loads and read barriers. The problem can also be observed in code generated for MIPS and LoongAarch, though we aren't currently testing those with Clang, and on x86, though we use our own assembler there. The scariest aspect is that we use the generic version on very common ARM systems, but it doesn't seem to reorder the relevant code there (or we'd have debugged this long ago). Fix by inserting an explicit compiler barrier. It expands to an empty assembler block declared to have memory side-effects, so registers are flushed and reordering is prevented. In those respects this is like the architecture-specific assembler versions, but the compiler is still in charge of generating the appropriate fence instruction. Done for write barriers on principle, though concrete problems have only been observed with read barriers. Reported-by: Alexander Lakhin <exclusion@gmail.com> Tested-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/d79691be-22bd-457d-9d90-18033b78c40a%40gmail.com Backpatch-through: 13 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1c7cba4c52953d2486a1465ea8d91ff65c35610c Modified Files -------------- src/include/port/atomics/generic-gcc.h | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix generic read and write barriers for Clang. @ 2025-11-07 23:40 Thomas Munro <tmunro@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Thomas Munro @ 2025-11-07 23:40 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix generic read and write barriers for Clang. generic-gcc.h maps our read and write barriers to C11 acquire and release fences using compiler builtins, for platforms where we don't have our own hand-rolled assembler. This is apparently enough for GCC, but the C11 memory model is only defined in terms of atomic accesses, and our barriers for non-atomic, non-volatile accesses were not always respected under Clang's stricter interpretation of the standard. This explains the occasional breakage observed on new RISC-V + Clang animal greenfly in lock-free PgAioHandle manipulation code containing a repeating pattern of loads and read barriers. The problem can also be observed in code generated for MIPS and LoongAarch, though we aren't currently testing those with Clang, and on x86, though we use our own assembler there. The scariest aspect is that we use the generic version on very common ARM systems, but it doesn't seem to reorder the relevant code there (or we'd have debugged this long ago). Fix by inserting an explicit compiler barrier. It expands to an empty assembler block declared to have memory side-effects, so registers are flushed and reordering is prevented. In those respects this is like the architecture-specific assembler versions, but the compiler is still in charge of generating the appropriate fence instruction. Done for write barriers on principle, though concrete problems have only been observed with read barriers. Reported-by: Alexander Lakhin <exclusion@gmail.com> Tested-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/d79691be-22bd-457d-9d90-18033b78c40a%40gmail.com Backpatch-through: 13 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d8ba910b09c0573ac795a15ff5ec75f3b3692d5f Modified Files -------------- src/include/port/atomics/generic-gcc.h | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix generic read and write barriers for Clang. @ 2025-11-07 23:40 Thomas Munro <tmunro@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Thomas Munro @ 2025-11-07 23:40 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix generic read and write barriers for Clang. generic-gcc.h maps our read and write barriers to C11 acquire and release fences using compiler builtins, for platforms where we don't have our own hand-rolled assembler. This is apparently enough for GCC, but the C11 memory model is only defined in terms of atomic accesses, and our barriers for non-atomic, non-volatile accesses were not always respected under Clang's stricter interpretation of the standard. This explains the occasional breakage observed on new RISC-V + Clang animal greenfly in lock-free PgAioHandle manipulation code containing a repeating pattern of loads and read barriers. The problem can also be observed in code generated for MIPS and LoongAarch, though we aren't currently testing those with Clang, and on x86, though we use our own assembler there. The scariest aspect is that we use the generic version on very common ARM systems, but it doesn't seem to reorder the relevant code there (or we'd have debugged this long ago). Fix by inserting an explicit compiler barrier. It expands to an empty assembler block declared to have memory side-effects, so registers are flushed and reordering is prevented. In those respects this is like the architecture-specific assembler versions, but the compiler is still in charge of generating the appropriate fence instruction. Done for write barriers on principle, though concrete problems have only been observed with read barriers. Reported-by: Alexander Lakhin <exclusion@gmail.com> Tested-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/d79691be-22bd-457d-9d90-18033b78c40a%40gmail.com Backpatch-through: 13 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/77b5b2c6f47cce79c64d7f5772e24e671bb507ad Modified Files -------------- src/include/port/atomics/generic-gcc.h | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2025-11-07 23:40 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-11-07 23:39 pgsql: Fix generic read and write barriers for Clang. Thomas Munro <tmunro@postgresql.org> 2025-11-07 23:39 pgsql: Fix generic read and write barriers for Clang. Thomas Munro <tmunro@postgresql.org> 2025-11-07 23:39 pgsql: Fix generic read and write barriers for Clang. Thomas Munro <tmunro@postgresql.org> 2025-11-07 23:40 pgsql: Fix generic read and write barriers for Clang. Thomas Munro <tmunro@postgresql.org> 2025-11-07 23:40 pgsql: Fix generic read and write barriers for Clang. Thomas Munro <tmunro@postgresql.org> 2025-11-07 23:40 pgsql: Fix generic read and write barriers for Clang. Thomas Munro <tmunro@postgresql.org> 2025-11-07 23:40 pgsql: Fix generic read and write barriers for Clang. Thomas Munro <tmunro@postgresql.org>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox