https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83228
Bug ID: 83228
Summary: Remove optimistic assumptions about atomic ops in
optab.c
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
There are a number of assumptions in optabs.c:
...
diff --git a/gcc/optabs.c b/gcc/optabs.c
index 48e37f8..7f6f9f1 100644
--- a/gcc/optabs.c
+++ b/gcc/optabs.c
@@ -6079,6 +6079,7 @@ expand_atomic_test_and_set (rtx target, rtx mem, enum
memmodel model)
/* Failing all else, assume a single threaded environment and simply
perform the operation. */
if (!ret)
{
/* If the result is ignored skip the move to target. */
@@ -6358,6 +6359,7 @@ expand_atomic_load (rtx target, rtx mem, enum memmodel
model)
return NULL_RTX;
/* Otherwise assume loads are atomic, and emit the proper barriers. */
if (!target || target == const0_rtx)
target = gen_reg_rtx (mode);
@@ -6438,6 +6440,7 @@ expand_atomic_store (rtx mem, rtx val, enum memmodel
model, bool use_release)
}
/* Otherwise assume stores are atomic, and emit the proper barriers. */
expand_mem_thread_fence (model);
emit_move_insn (mem, val);
...
The assumptions make sense from the point of view of a target that is complete
and working: if say, the atomic load expansion is missing, it's because the
target intends to use the fallback, because regular loads are atomic.
But during a target bringup for a target where loads are not atomic, the
expansion might be missing because it's not done yet, in which case the
fallback silently gives the wrong answer, while it would be more helpful for
the compiler to ICE at that point, indicating that some support is missing.
So, in these cases we want to ICE by default, unless the target tells us to use
the fallback.
