C++ has a “forward progress” requirement for loops:

(6.9.2.3p1) The implementation may assume that any thread will eventually do one
of the following:

1. terminate,
2. invoke the function std​::​this_thread​::​yield ([thread.thread.this]),
3. make a call to a library I/O function,
4. perform an access through a volatile glvalue,
5. perform a synchronization operation or an atomic operation, or
6. continue execution of a trivial infinite loop ([stmt.iter.general]). [Added in C++23]

So an infinite loop that doesn’t do any of these things (and doesn’t meet the definition of a “trivial infinite loop”) causes undefined behavior.

For purposes of item 5, is a fence considered to be an “synchronization operation or atomic operation”? If we have a non-trivial infinite loop whose body contains an atomic_signal_fence() or atomic_thread_fence() but no other side effects, does this cause undefined behavior?

I don’t think there’s an explicit definition or exhaustive list of “atomic operations” anywhere in the standard. atomics.fences describes them as “synchronization primitives” instead, and arguably it doesn’t make sense for fences to count as observable effects here, because they don’t actually have any observable effects of their own. On the other hand, atomics.order p4, in another context, speaks of a total order on “all memory_order​::​seq_cst operations, including fences”, suggesting that they are considered “operations”.

Bonus question: does it make a difference if the fence has memory_order_relaxed ordering, which is explicitly defined as having no effect?

gcc and clang appear to differ here. Given code like

bool b = true;
while (b) {
   std::atomic_signal_fence(std::memory_order_relaxed);
}

clang will delete the entire loop, and indeed emit no code at all for the function, which is its typical behavior when a function unconditionally causes UB if called. Try on godbolt.

On the other hand, gcc will emit an infinite empty loop, even though it will happily delete such loops without a fence.

More elaborate example on godbolt.

The same thing happens for other memory orders and for atomic_thread_fence (in the latter case, gcc emits an infinite loop with a barrier instruction.)