Bug 233682 – [JSC] HeapBigInt CompareStrictEq should call use after speculation checks

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Lukas Bernhard]

During differential testing of webkit I found a sample triggering a miscomputation in FTL.

JSC on git commit: 65d77d21751c
build options:
./Tools/Scripts/build-jsc --jsc-only --release --cmakeargs="-DENABLE_STATIC_JSC=ON -DCMAKE_C_COMPILER='/usr/bin/clang-12' -DCMAKE_CXX_COMPILER='/usr/bin/clang++-12' -DCMAKE_CXX_FLAGS='-O3 -lrt -latomic -fuse-ld=lld'"

command line:
RefBuild/Release/bin/jsc --validateOptions=true --useConcurrentJIT=false --useConcurrentGC=false --validateBCE=true --thresholdForJITSoon=10 --thresholdForJITAfterWarmUp=10 --thresholdForOptimizeAfterWarmUp=100 --thresholdForOptimizeAfterLongWarmUp=100 --thresholdForOptimizeSoon=100 --thresholdForFTLOptimizeAfterWarmUp=1000 diff.js

differs from:
RefBuild/Release/bin/jsc --validateOptions=true --useConcurrentJIT=false --useConcurrentGC=false --validateBCE=true --useFTLJIT=false diff.js


```
function main() { 
    let v37;
    let v20 = 129n << 129n;
    const v21 = v20++;
        
    function v29(v30) {
        switch (v21) {
        default:
            for (let v34 = 1; v34 < 65536; v34++) { } 
            break;
        case v30: 
            v37 = 1; // should never be reached, however this is executed in baseline
        }   
    }   
        
    v29(BigInt(129n));
    v29([1]);
        
    print(v37);  // prints 1 without FTL, undefined with FLT (also undefined in spidermonkey)
}
main();
```

[Radar WebKit Bug Importer]

<rdar://problem/86192953>

[Lukas Bernhard]

While I understand this issue might not be of high relevance, I encounter this correctness error quite often during fuzzing. This makes deduplication of findings rather tedious.
If fixing the underlying problem is not in scope for now, could the engine maybe emit some kind of fprintf(stderr, "known correctness error") so fuzzers could skip the particular problem?

[Saam Barati]

(In reply to Lukas Bernhard from comment #2)
> While I understand this issue might not be of high relevance, I encounter
> this correctness error quite often during fuzzing. This makes deduplication
> of findings rather tedious.
> If fixing the underlying problem is not in scope for now, could the engine
> maybe emit some kind of fprintf(stderr, "known correctness error") so
> fuzzers could skip the particular problem?

Yeah, this should just be fixed to unblock the fuzzer.

[Yusuke Suzuki]

Pull request: https://github.com/WebKit/WebKit/pull/4510

[EWS]

Committed 254655@main (662e9f67690e): <https://commits.webkit.org/254655@main>

Reviewed commits have been landed. Closing PR #4510 and removing active labels.