https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118977
--- Comment #8 from Joel Sherrill <joel at gcc dot gnu.org> --- (In reply to Hans-Peter Nilsson from comment #5) > (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 <[email protected]> > > 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.) On targets without atomic instructions, we fall back to an implementation which disables processor interrupts. These are generally embedded CPUs which are not multi-core and disabling interrupts is sufficient.
