Okay, I need to figure out whether this bug is user-mode or system-mode related in QEMU. The user mentioned they upgraded to qemu-5.0 and started seeing random failures in the GCC testsuite, specifically g++.dg/ext/sync-4.C. The issue occurs when executing __aarch64_cas8_acq_rel, leading to a call to abort(). Looking at the provided code snippets: - f13 is a function that uses __sync_bool_compare_and_swap on a pointer. - t13 calls f13 with a null pointer and catches exceptions. If no exception is thrown, it calls abort(). The traces show execution starting from main, calling f13 which then invokes __aarch64_cas8_acq_rel. After returning, it goes to abort(). I recall that __sync_bool_compare_and_swap is a GCC built-in for atomic operations. On AArch64, this uses the CAS instruction, which might be handled by QEMU's user-mode emulation. The problem arises during the execution of an atomic compare-and-swap operation, suggesting it's related to how QEMU emulates these instructions in user mode. Since the issue doesn't occur on native hardware but does in QEMU, it points towards a bug in QEMU's handling of AArch64 atomic operations. System-mode issues usually involve higher privileges or devices, which isn't indicated here. The problem seems isolated to the execution of a specific instruction, pointing more towards user-mode emulation. So, this is likely a user-mode issue because it's related to how QEMU handles certain instructions in user space rather than system-level components. user