https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118977
--- Comment #5 from Hans-Peter Nilsson <hp at gcc dot gnu.org> --- (In reply to Joel Sherrill from comment #4) > I managed to narrow down the commit that broke this. RTEMS has some > functions to support libatomic in libatomic/config/rtems. What tiny bit of > magic are we missing for CPUs that don't have the instruction. Help > providing __atomic_test_and_set is appreciated. > > > commit 8e6757b30d0f3f13d47d0f842801a751ba6293c2 (HEAD) > Author: Hans-Peter Nilsson <h...@axis.com> Being the author of a commit you called out as "breaking", I feel obliged to reply. If you mean that generated code was "working" before, then just add code to your libgcc, equivalent to e.g. open-coded *non-atomic* test-and-set code and pretend it's fixed: state pre-commit is effectively restored. (Also, FAOD: definitely wrong.) For correctness, unfortunately I can only offer the obvious alternative: add to your libgcc a test-and-set implementation expressed using whatever atomic operations *are* available for your target. If you don't have any at all, then you never had atomicity and you might as well e.g. wrap open-coded operations in flag-save/disabling-interrupts and restoring flags afterwards. No practical examples of any of that for m68k, sorry.
