The compiler doesn't really play a role in this. If a syscall changes, then you'll need to change the arguments in the C code that invokes it.

The system libraries like libc themselves use syscalls internally, yes. But on those platforms I'm talking about, they're maintained by the same people who maintain the kernel, and both components are versioned together. So they can go and change a syscall, and then also make the corresponding change to libc (without changing the latter's public ABI), and ship the updated versions together as the new OS release. Well-behaved apps dynamically link against libc, so the change is completely transparent to them.

On Linux, different people maintain the kernel and libc (and, in fact, there's no single officially blessed libc - this is one case where the old adage that "Linux is just a kernel" is in full force). Consequently, the interface between the two has to be treated as a public API, with stability guarantees.

The system's C library would use the syscalls directly and the application would use the C library routines. So if/when the OS updates the syscall ABI, it would also update the system's C library to use the new syscalls, and the application would continue to use the stable C library API and get the new syscalls under the covers automatically.