throwing std::runtime on PC BSP fails

[Joel Sherrill]

Copied from #2830 for new release milestone. The solution is to update gcc/config/i386/t-rtems. Whether for gcc 10 or gcc master is the difference on this CR versus #2830 which had to be to gcc 7 as a patch via the RSB.

Throwing a std::runtime() exception locks up.

The lock up is in the exception clean up handler where the exception object is destructed. The destructor loops distructing the std::string object. The path ends up in libstdc++-v3/include/ext/atomicity.h line 48 or exchange_and_add.

At a guess it would seem like the C++ atomics on i386 is broken or fragile.

UPDATE: This was broken when gcc i386 eliminated -mcpu in favor of -march/-mtune. The multilibs were built with -mtune and not -march.

[Joel Sherrill]

Patch for GCC 10 to fix multilib compiler arguments on i386

[Michael Davidsaver <mdavidsaver@…>]

In 1ea1c9c/rtems-source-builder:

patch gcc i386 multiarch

Add patch to change from mtune to march when building multilibs.
The mtune argument tunes or optimizes for a specific CPU model but
does not ensure the generated code is appropriate for the
CPU model. Prior to this patch, i386 compatible code was always
generated but tuned for later models.

This is the same fix as #2830 but applying to gcc 10.

Updates #4084.

[Joel Sherrill]

Post for GCC 10 and master posted ​https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554430.html

[Joel Sherrill]

I applied the GCC patch to the master and 10 release branch.

​https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=63a32847b0e8d14ae1eafe047ea43441f6e3a11c