If GCC accepts C11 atomic_int casts and clang rejects them, which is correct?

Suppose I have the following C11 program:

#include <stdatomic.h>

int
main()
{
        int x = 0; // same behaviour if `atomic_int x`, surprisingly
        atomic_int y = (atomic_int) x;
}

If I compile this with gcc 9, I get no errors. If I compile it with Apple clang 11, I get:

foo.c:7:17: error: used type 'atomic_int' (aka '_Atomic(int)') where arithmetic or
      pointer type is required
        atomic_int y = (atomic_int) x;

Similar issues abound when using a variety of godbolt versions of GCC, Clang, and other compilers that support C11, on various platforms. This happens regardless of whether --std=c11 is set.

A quick read of the draft C11 standard says (in 6.5.4) that 'the type name shall specify atomic, qualified, or unqualified scalar type, and the operand shall have scalar type.', which suggests that the cast is legal - I can't see anything that would say otherwise.

So, my question is this: is clang in the wrong here? Are the other compilers incorrectly accepting this cast? Is this somewhere in which clang and gcc are allowed to differ?

(The wider context, incidentally, is that I'm using a third-party program that generates C code that includes, amongst other things, a cast from intmax_t to atomic_int. This cast works on gcc, which is the sole supported compiler for that program, but fails on clang --- and, therefore, macOS's gcc, which is an alias to clang. I'm trying to work out where the fault lies --- clang for rejecting valid code, the program for generating invalid code, or macOS for pretending a compiler that isn't a drop-in replacement for gcc is.)