131508 2014-04-10 14:16:55 -0700 win64 build fix 2014-04-14 07:20:27 -0700 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 1 alex.christensen webkit-unassigned commit-queue ggaren oldest_to_newest 999648 0 alex.christensen 2014-04-10 14:16:55 -0700 In 64-bit Windows, "unsigned" means a 32-bit unsigned integer, "size_t" means a 64-bit unsigned integer, and "unsigned long" means a 32-bit unsigned integer. Visual Studio is having trouble deciding whether to use std::min<unsigned> or std::min<size_t> in X86Assembler.h. Here's a simple fix. 999650 1 229080 alex.christensen 2014-04-10 14:19:47 -0700 Created attachment 229080 Patch 999744 2 229080 ggaren 2014-04-10 18:46:26 -0700 Comment on attachment 229080 Patch r=me 999749 3 229080 commit-queue 2014-04-10 19:18:03 -0700 Comment on attachment 229080 Patch Clearing flags on attachment: 229080 Committed r167108: <http://trac.webkit.org/changeset/167108> 999750 4 commit-queue 2014-04-10 19:18:06 -0700 All reviewed patches have been landed. Closing bug. 1000202 5 229080 darin 2014-04-12 11:58:18 -0700 Comment on attachment 229080 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=229080&action=review > Source/JavaScriptCore/assembler/X86Assembler.h:2276 > - unsigned nopSize = std::min(size, 15UL); > + unsigned nopSize = std::min<unsigned>(size, 15UL); Once we add <unsigned>, then there is no point in having the UL there any more. The L is particularly silly, since it gives us an unsigned long constant for no good reason. Also, this function won’t work for any sizes that are greater than the maximum unsigned. It probably should either take an argument of type unsigned or work properly for large values of type size_t. Taking a size_t, and malfunctioning, seems like a strange choice. 1000241 6 alex.christensen 2014-04-12 18:37:07 -0700 (In reply to comment #5) > Also, this function won’t work for any sizes that are greater than the maximum unsigned. It probably should either take an argument of type unsigned or work properly for large values of type size_t. Taking a size_t, and malfunctioning, seems like a strange choice. I was shooting for a non-invasive fix, and I was assuming that size wouldn't get anywhere near ULONG_MAX. Do you think it would be worth switching all the unsigned types to size_t? I'm a big fan of using size_t unless a different type is needed, but I also don't work on JavaScriptCore much and don't want to muck up their code. 1000478 7 alex.christensen 2014-04-14 07:20:27 -0700 You're right, Darin. A fix is in https://bugs.webkit.org/show_bug.cgi?id=131615 229080 2014-04-10 14:19:47 -0700 2014-04-12 11:58:18 -0700 Patch bug-131508-20140410151931.patch text/plain 1382 alex.christensen SW5kZXg6IFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291 cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwkocmV2aXNpb24gMTY3MDg2KQorKysgU291cmNl L0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE0IEBA CisyMDE0LTA0LTEwICBBbGV4IENocmlzdGVuc2VuICA8YWNocmlzdGVuc2VuQHdlYmtpdC5vcmc+ CisKKyAgICAgICAgQ29tcGlsZSBmaXggZm9yIFdpbjY0LgorICAgICAgICBodHRwczovL2J1Z3Mu d2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTMxNTA4CisKKyAgICAgICAgUmV2aWV3ZWQgYnkg Tk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgKiBhc3NlbWJsZXIvWDg2QXNzZW1ibGVyLmg6Cisg ICAgICAgIChKU0M6Olg4NkFzc2VtYmxlcjo6ZmlsbE5vcHMpOgorICAgICAgICBBZGRlZCB1bnNp Z25lZCB0ZW1wbGF0ZSBwYXJhbWV0ZXIgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBzaXplX3QgYW5k IHVuc2lnbmVkIGxvbmcuCisKIDIwMTQtMDQtMTAgIEJyaWFuIEouIEJ1cmcgIDxidXJnQGNzLndh c2hpbmd0b24uZWR1PgogCiAgICAgICAgIFdlYiBSZXBsYXk6IG1lbW9pemUgcGx1Z2luIGRhdGEg Zm9yIG5hdmlnYXRvci5taW1lVHlwZXMgYW5kIG5hdmlnYXRvci5wbHVnaW5zCkluZGV4OiBTb3Vy Y2UvSmF2YVNjcmlwdENvcmUvYXNzZW1ibGVyL1g4NkFzc2VtYmxlci5oCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9hc3NlbWJsZXIvWDg2QXNzZW1ibGVyLmgJKHJldmlzaW9u IDE2NzA4NikKKysrIFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9hc3NlbWJsZXIvWDg2QXNzZW1ibGVy LmgJKHdvcmtpbmcgY29weSkKQEAgLTIyNzMsNyArMjI3Myw3IEBAIHB1YmxpYzoKIAogICAgICAg ICB1aW50OF90KiB3aGVyZSA9IHJlaW50ZXJwcmV0X2Nhc3Q8dWludDhfdCo+KGJhc2UpOwogICAg ICAgICB3aGlsZSAoc2l6ZSkgewotICAgICAgICAgICAgdW5zaWduZWQgbm9wU2l6ZSA9IHN0ZDo6 bWluKHNpemUsIDE1VUwpOworICAgICAgICAgICAgdW5zaWduZWQgbm9wU2l6ZSA9IHN0ZDo6bWlu PHVuc2lnbmVkPihzaXplLCAxNVVMKTsKICAgICAgICAgICAgIHVuc2lnbmVkIG51bVByZWZpeGVz ID0gbm9wU2l6ZSA8PSAxMCA/IDAgOiBub3BTaXplIC0gMTA7CiAgICAgICAgICAgICBmb3IgKHVu c2lnbmVkIGkgPSAwOyBpICE9IG51bVByZWZpeGVzOyArK2kpCiAgICAgICAgICAgICAgICAgKndo ZXJlKysgPSAweDY2Owo=