<html>
    <head>
      <base href="https://bugs.webkit.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - [Win] Fix for JSC stress test failures."
   href="https://bugs.webkit.org/show_bug.cgi?id=156343#c6">Comment # 6</a>
              on <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - [Win] Fix for JSC stress test failures."
   href="https://bugs.webkit.org/show_bug.cgi?id=156343">bug 156343</a>
              from <span class="vcard"><a class="email" href="mailto:fpizlo&#64;apple.com" title="Filip Pizlo &lt;fpizlo&#64;apple.com&gt;"> <span class="fn">Filip Pizlo</span></a>
</span></b>
        <pre>By the way: the fact that load and friends take const void* instead of AbsoluteAddress and they take GPRReg instead of Address (via the weird ImplicitAddress thing) is a vestige of a past long gone.

It would be super cool to replace all cases of the assembler taking void* and change them to take AbsoluteAddress.  It would also be cool to get rid of ImplicitAddress and make everyone use Address.

It's not obvious why MSVC interpreted the code the way that it did, but I can sort of see it, and it's scary to think just how much our load() and store() methods rely on very specific interpretations of overload resolution to work properly.  A RegisterID/GPRReg is just an enum, which coerces to int, and regT0 is a zero-valued enum.  We want MSVC to realize that the preferred overload resolution is to coerce to ImplicitAddress, but apparently due to the zeroish nature of regT0, it's treating it as null-like and coercing to void*.  Whether that's right or wrong, I don't really care, because I don't like it when the correctness of code relies so much on C++'s arcane overload resolution rules.  Therefore, I think that this change is a big win for correctness, and I think we should use Address() explicitly in more places.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>