[BigSur wk1 arm64] platform/mac/fast/objc/longlongTest.html is a consistent failure

[Amir Mark Jr]

platform/mac/fast/objc/longlongTest.html

Is a consistent failure on Big Sur Wk1 Apple Silicon machines.

History:

https://results.webkit.org/?suite=layout-tests&test=platform%2Fmac%2Ffast%2Fobjc%2FlonglongTest.html

Diff:

--- /Volumes/Data/worker/bigsur-release-applesilicon-tests-wk1/build/layout-test-results/platform/mac/fast/objc/longlongTest-expected.txt
+++ /Volumes/Data/worker/bigsur-release-applesilicon-tests-wk1/build/layout-test-results/platform/mac/fast/objc/longlongTest-actual.txt
@@ -1,7 +1,7 @@
 PASS Test LongLong: result is 0 as expected!
 PASS Test LongLong: result is 1 as expected!
 PASS Test LongLong: result is -1 as expected!
-PASS Test LongLong: result is -9223372036854776000 as expected!
+FAIL Test LongLong: result is 9223372036854776000, should be -9223372036854776000
 PASS Test LongLong: result is -9223372036854776000 as expected!
 PASS Test UnsignedLongLong: result is 0 as expected!
 PASS Test UnsignedLongLong: result is 1 as expected!

[Radar WebKit Bug Importer]

<rdar://problem/75286103>

[Amir Mark Jr]

I cannot reproduce failure due to not having access to an Apple Silicon machine.

[Chris Dumez]

Similar to https://bugs.webkit.org/show_bug.cgi?id=223050, I will look tomorrow.

[Mark Lam]

*** Bug 223084 has been marked as a duplicate of this bug. ***

[Mark Lam]

The issue is that the test is expecting convertValueToObjcValue()'s conversion of double to long long to follow x86_64 semantics.  I don't think there's a specification for this behaviors (falls under undefined behavior).  I'll just change the code such that it emulates x86_64 behavior to placate the test.

[Mark Lam]

Created attachment 422959 [details]
proposed patch.

[Yusuke Suzuki]

Comment on attachment 422959 [details]
proposed patch.

View in context: https://bugs.webkit.org/attachment.cgi?id=422959&action=review

r=me too

> Source/WebCore/bridge/objc/objc_utility.mm:87
> +#if CPU(ARM64)
> +    // Match x86_64 semantics which allows for overflow.
> +    long long potentiallyOverflowed = (unsigned long long)d;
> +    if (potentiallyOverflowed < (long long)d)
> +        return potentiallyOverflowed;
> +#endif

Why not always using this path?

[Mark Lam]

(In reply to Yusuke Suzuki from comment #7)
> Comment on attachment 422959 [details]
> proposed patch.
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=422959&action=review
> 
> r=me too
> 
> > Source/WebCore/bridge/objc/objc_utility.mm:87
> > +#if CPU(ARM64)
> > +    // Match x86_64 semantics which allows for overflow.
> > +    long long potentiallyOverflowed = (unsigned long long)d;
> > +    if (potentiallyOverflowed < (long long)d)
> > +        return potentiallyOverflowed;
> > +#endif
> 
> Why not always using this path?

I guess I can make it do that.

[Mark Lam]

Created attachment 422961 [details]
patch for landing.

[Mark Lam]

Comment on attachment 422961 [details]
patch for landing.

Thanks for the reviews.  Landing now.

[EWS]

Committed r274313: <https://commits.webkit.org/r274313>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 422961 [details].