Bug 80080

Summary: WebKit compiled by gcc (Xcode 3.2.6) hangs while running DOM/Accessors.html
Product: WebKit Reporter: Ryosuke Niwa <rniwa>
Component: Web Template FrameworkAssignee: Ryosuke Niwa <rniwa>
Status: RESOLVED FIXED    
Severity: Normal CC: andersca, fpizlo, oliver
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
My desparate attempt to fix JSC fpizlo: review+

Description Ryosuke Niwa 2012-03-01 18:48:11 PST
I attempted a fix in http://trac.webkit.org/changeset/109478 but it had to be reverted due to a build failure: http://trac.webkit.org/changeset/109481

Not sure what the right fix is here.
Comment 1 Filip Pizlo 2012-03-01 18:50:18 PST
(In reply to comment #0)
> I attempted a fix in http://trac.webkit.org/changeset/109478 but it had to be reverted due to a build failure: http://trac.webkit.org/changeset/109481
> 
> Not sure what the right fix is here.

The build failure is due to the fact that on 32-bit, uintptr_t and unsigned might be the same type.  Well, they're always compatible in type in the sense that unsigned and uintptr_t will both be 32-bit but there's an open question as to whether uintptr_t is "unsigned int" or "unsigned long".

The most robust solution is to rename the two weakCompareAndSwaps to:

weakCompareAndSwapUnsigned(...)

and:

weakCompareAndSwapPointer(...)

Then there won't be problems.
Comment 2 Ryosuke Niwa 2012-03-09 15:19:51 PST
Created attachment 131123 [details]
My desparate attempt to fix JSC
Comment 3 Filip Pizlo 2012-03-09 15:21:13 PST
Comment on attachment 131123 [details]
My desparate attempt to fix JSC

I like this approach - this side-steps all manner of C++ overload strangeness due to the plethora of ways that uintptr_t can be typedef'd.  R=me.
Comment 4 Ryosuke Niwa 2012-03-09 15:25:27 PST
Committed r110342: <http://trac.webkit.org/changeset/110342>