[Webkit-unassigned] [Bug 155371] build fails with memory model cannot be stronger than success memory model for ‘__atomic_compare_exchange’

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Sep 13 22:13:59 PDT 2016


https://bugs.webkit.org/show_bug.cgi?id=155371

JF Bastien <jfbastien at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|webkit-unassigned at lists.web |jfbastien at apple.com
                   |kit.org                     |
 Attachment #283631|0                           |1
        is obsolete|                            |
 Attachment #288772|                            |review?
              Flags|                            |

--- Comment #12 from JF Bastien <jfbastien at apple.com> ---
Created attachment 288772
  --> https://bugs.webkit.org/attachment.cgi?id=288772&action=review
patch which inlines all atomics instead

I don't think this is the right fix. I've attached a different one. TL;DR the quick fix is to make these wrapper function ALWASY_INLINE.

Details:

I tested with a few GCC versions, and the problem is specific to pre-5 revisions of GCC at Os only. The reason is that libstdc++ tries to be clever about enforcing the C++ standard's clause [atomics.types.operations.req] ¶21 which states:

    Requires: The failure argument shall not be `memory_order_release` nor
    `memory_order_acq_rel`. The failure argument shall be no stronger than the
    success argument.

It fails at doing this because its inlining heuristics are modified by Os, and they're not quite as dumb as O0 but not smart enough to get to the good code at O1. Adding ALWAYS_INLINE fixes the silliness at Os, leaves O1 great, and makes O0 slightly less bad but still pretty bad.

Try it out here: https://godbolt.org/g/8FPxWt


The other good news is that I'm going to get this particular problem fixed in the version of C++ which will come after C++17:
https://github.com/jfbastien/papers/blob/master/source/P0418r1.bs

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160914/13d697bb/attachment.html>


More information about the webkit-unassigned mailing list