Who's afraid of a big bad optimizing compiler?
Who's afraid of a big bad optimizing compiler?
Posted Jul 26, 2019 18:11 UTC (Fri) by andresfreund (subscriber, #69562)In reply to: Who's afraid of a big bad optimizing compiler? by law@redhat.com
Parent article: Who's afraid of a big bad optimizing compiler?
I agree. Although I still don't understand why the C11/C++11 memory model chose to provide barriers not tied to variables in such an oddly defined way. IIRC - and it's been a while since I tried to parse the standard's language - you can't really use them to incrementally upgrade from compiler-specific barriers, without also converting all other memory to go through C11/C++11 atomics.
Posted Aug 15, 2019 19:15 UTC (Thu)
by PaulMcKenney (✭ supporter ✭, #9624)
[Link]
Who's afraid of a big bad optimizing compiler?
There were some concerns about specific machines that have since proved groundless, so the atomic_thread_fence() wording has (quite) recently been upgraded.