12020-09-24T00:00:02  *** rah1 has quit IRC
  22020-09-24T00:02:40  *** kristapsk has quit IRC
  32020-09-24T00:03:03  *** kristapsk has joined #bitcoin-core-dev
  42020-09-24T00:12:02  *** davterra has quit IRC
  52020-09-24T00:12:22  *** pinheadmz has joined #bitcoin-core-dev
  62020-09-24T00:13:32  *** pinheadm_ has quit IRC
  72020-09-24T00:16:00  *** davterra has joined #bitcoin-core-dev
  82020-09-24T00:22:05  *** nirik-fre has joined #bitcoin-core-dev
  92020-09-24T00:35:12  *** kristapsk has quit IRC
 102020-09-24T00:35:52  *** kristapsk has joined #bitcoin-core-dev
 112020-09-24T00:38:34  *** nirik-fre has quit IRC
 122020-09-24T00:43:22  *** kristapsk has quit IRC
 132020-09-24T00:47:49  *** S3RK has quit IRC
 142020-09-24T00:48:01  *** S3RK has joined #bitcoin-core-dev
 152020-09-24T00:54:02  *** TheRec has quit IRC
 162020-09-24T00:54:45  *** TheRec has joined #bitcoin-core-dev
 172020-09-24T00:58:19  *** AaronvanW has joined #bitcoin-core-dev
 182020-09-24T01:03:00  *** spinza has quit IRC
 192020-09-24T01:03:42  *** spinza has joined #bitcoin-core-dev
 202020-09-24T01:28:44  *** AaronvanW has quit IRC
 212020-09-24T01:31:08  *** xchg has joined #bitcoin-core-dev
 222020-09-24T01:43:18  *** Eagle[TM] has joined #bitcoin-core-dev
 232020-09-24T01:44:47  *** EagleTM has quit IRC
 242020-09-24T01:48:23  *** Highway61 has quit IRC
 252020-09-24T02:21:00  *** Althea-told-me has quit IRC
 262020-09-24T02:22:01  <luke-jr> FWIW, I just had a 0.13 wallet go corrupt (so sipa's instance probably wasn't a regression)
 272020-09-24T02:29:59  *** tryphe has quit IRC
 282020-09-24T02:30:42  *** tryphe has joined #bitcoin-core-dev
 292020-09-24T02:32:53  *** meshcollider has joined #bitcoin-core-dev
 302020-09-24T02:46:25  <luke-jr> anyone know off-hand what GCC we use in gitian builds? :x
 312020-09-24T02:48:45  <sipa> linux builds use bionic, so GCC 7 i believe
 322020-09-24T02:49:09  *** andreacab has joined #bitcoin-core-dev
 332020-09-24T02:51:19  <luke-jr> sipa: do you happen to know this bug in detail enough, to be able to reasonably tell if we would be affected at all?
 342020-09-24T02:53:06  <luke-jr> I suppose the only way to be _sure_ would be to do a before/after build using GCC master and master minus 1
 352020-09-24T02:53:29  <sipa> luke-jr: affected, i think yes - in particular the cnetaddr code may incorrectly classify IP addresses
 362020-09-24T02:53:52  <sipa> i'll look deeper into whether that is actually an issue
 372020-09-24T02:54:17  *** andreacab has quit IRC
 382020-09-24T03:00:02  *** xchg has quit IRC
 392020-09-24T03:00:48  <luke-jr> it would be funny if compilers turned memcmp(…) > -2 and  memcmp(…) < 2 into a constant 1 <.<
 402020-09-24T03:01:43  <sipa> actually, looking at the code in 0.20, and my understanding of the bug, i don't see why it wouldn't make IsIPv4() return true for literally every address
 412020-09-24T03:03:05  <sipa> so i'm probably misunderstanding the bug
 422020-09-24T03:07:26  <luke-jr> h mm
 432020-09-24T03:09:37  <roconnor> Based on my limited experimation it does seem limited to cases where the static array begins with 0.
 442020-09-24T03:09:44  <roconnor> Though I don't really understand why.
 452020-09-24T03:09:59  <sipa> that happens to be the case for the IsIPv4 code
 462020-09-24T03:11:47  <luke-jr> is it constexpr?
 472020-09-24T03:12:10  <sipa> it should be
 482020-09-24T03:12:35  <luke-jr> FWIW it looks like the fix is a clean apply to 10.2, so I'm doing a before/after build
 492020-09-24T03:12:51  <sipa> what fix? to what?
 502020-09-24T03:13:06  <luke-jr> https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=d5803b9876b3d11c93d1a10fabb3fbb1c4a14bd6;hp=3e99ed65cbedf7a6c0abb9cd63c191326995fd34
 512020-09-24T03:13:29  <sipa> https://github.com/bitcoin/bitcoin/blob/v0.20.1/src/netaddress.cpp#L12 and https://github.com/bitcoin/bitcoin/blob/v0.20.1/src/netaddress.cpp#L127
 522020-09-24T03:13:54  <luke-jr> sipa: I'm building Knots with 10.2 and then 10.2 patched with the fix, then comparing to see if anything changed
 532020-09-24T03:14:03  <sipa> ah, good idea
 542020-09-24T03:14:44  <roconnor> Does IsIPv4 always return true?
 552020-09-24T03:15:15  <luke-jr> I guess if it only affects a minority of nodes, it could and we might not notice?
 562020-09-24T03:15:57  <sipa> this test should fail: https://github.com/bitcoin/bitcoin/blob/v0.20.1/src/test/netbase_tests.cpp#L53
 572020-09-24T03:16:11  <sipa> (is IsIPv6() calls !IsIPv4() && ...)
 582020-09-24T03:16:18  <luke-jr> hrm
 592020-09-24T03:19:06  <luke-jr> doh, was building with LLVM
 602020-09-24T03:19:10  * luke-jr starts over quickly
 612020-09-24T03:24:02  *** bitcoin-git has joined #bitcoin-core-dev
 622020-09-24T03:24:02  <bitcoin-git> [bitcoin] ajtowns closed pull request #19970: sync.h: fix LockAssertion error reporting (master...202009-lockassertion) https://github.com/bitcoin/bitcoin/pull/19970
 632020-09-24T03:24:03  *** bitcoin-git has left #bitcoin-core-dev
 642020-09-24T03:26:06  *** AaronvanW has joined #bitcoin-core-dev
 652020-09-24T03:30:45  <roconnor> https://github.com/bitcoin/bitcoin/blob/0.20/src/netaddress.cpp#L237 also. ... assuming that IsIPv4 somehow isn't always returning true.
 662020-09-24T03:31:03  <roconnor> Though that test file does seem to be run.
 672020-09-24T03:47:14  *** sr_gi has quit IRC
 682020-09-24T03:47:50  *** sr_gi has joined #bitcoin-core-dev
 692020-09-24T03:57:01  *** gholms1 has joined #bitcoin-core-dev
 702020-09-24T03:59:49  *** AaronvanW has quit IRC
 712020-09-24T04:09:08  *** davec has quit IRC
 722020-09-24T04:09:30  *** davec has joined #bitcoin-core-dev
 732020-09-24T04:28:35  *** dermoth has quit IRC
 742020-09-24T04:30:55  *** dermoth has joined #bitcoin-core-dev
 752020-09-24T04:43:55  *** tralfaz has joined #bitcoin-core-dev
 762020-09-24T04:47:14  *** davterra has quit IRC
 772020-09-24T05:12:41  *** ossifrage_ has joined #bitcoin-core-dev
 782020-09-24T05:13:35  *** S3RK has quit IRC
 792020-09-24T05:14:03  *** S3RK has joined #bitcoin-core-dev
 802020-09-24T05:15:35  *** ossifrage has quit IRC
 812020-09-24T05:32:30  *** tralfaz is now known as davterra
 822020-09-24T05:34:41  *** MrPaz has quit IRC
 832020-09-24T05:56:49  *** AaronvanW has joined #bitcoin-core-dev
 842020-09-24T06:00:01  *** gholms1 has quit IRC
 852020-09-24T06:11:57  *** jonatack has quit IRC
 862020-09-24T06:12:48  *** jonatack has joined #bitcoin-core-dev
 872020-09-24T06:21:13  *** sdx23 has joined #bitcoin-core-dev
 882020-09-24T06:21:41  *** sdx23 is now known as Guest48547
 892020-09-24T06:28:32  *** gloriazhao has quit IRC
 902020-09-24T06:29:26  *** AaronvanW has quit IRC
 912020-09-24T06:35:38  *** balbirs has quit IRC
 922020-09-24T06:35:57  *** balbirs has joined #bitcoin-core-dev
 932020-09-24T06:50:50  *** andreacab has joined #bitcoin-core-dev
 942020-09-24T06:55:35  *** andreacab has quit IRC
 952020-09-24T07:01:16  <kallewoof> sipa: technically it was thursday when you said 'hi' 12 hours ago. it just wasn't thursday in the right place (it was thursday in japan tho)
 962020-09-24T07:06:40  *** opsec_x12 has joined #bitcoin-core-dev
 972020-09-24T07:07:33  *** sdaftuar has quit IRC
 982020-09-24T07:07:59  *** sdaftuar has joined #bitcoin-core-dev
 992020-09-24T07:12:26  *** andreacab has joined #bitcoin-core-dev
1002020-09-24T07:16:07  *** justanotheruser has quit IRC
1012020-09-24T07:19:48  *** marcoagner has joined #bitcoin-core-dev
1022020-09-24T07:36:23  *** S3RK has quit IRC
1032020-09-24T07:36:29  *** S3RK has joined #bitcoin-core-dev
1042020-09-24T07:39:29  *** andreacab has quit IRC
1052020-09-24T07:39:55  *** andreacab has joined #bitcoin-core-dev
1062020-09-24T07:45:37  *** andreacab has quit IRC
1072020-09-24T07:53:12  *** bitcoin-git has joined #bitcoin-core-dev
1082020-09-24T07:53:12  <bitcoin-git> [bitcoin] naumenkogs closed pull request #19958: p2p: Better document features of feelers (master...2020-09-rename-feeler-to-probe) https://github.com/bitcoin/bitcoin/pull/19958
1092020-09-24T07:53:13  *** bitcoin-git has left #bitcoin-core-dev
1102020-09-24T07:53:32  *** bitcoin-git has joined #bitcoin-core-dev
1112020-09-24T07:53:32  <bitcoin-git> [bitcoin] naumenkogs reopened pull request #19958: p2p: Better document features of feelers (master...2020-09-rename-feeler-to-probe) https://github.com/bitcoin/bitcoin/pull/19958
1122020-09-24T07:53:40  *** bitcoin-git has left #bitcoin-core-dev
1132020-09-24T08:06:41  *** andreacab has joined #bitcoin-core-dev
1142020-09-24T08:12:37  <sipa> kallewoof: timezones are evil
1152020-09-24T08:15:36  *** AaronvanW has joined #bitcoin-core-dev
1162020-09-24T08:21:31  *** sipsorcery has joined #bitcoin-core-dev
1172020-09-24T08:23:55  *** jonatack has quit IRC
1182020-09-24T08:36:26  *** Guest48547 has quit IRC
1192020-09-24T08:41:34  *** bitcoin-git has joined #bitcoin-core-dev
1202020-09-24T08:41:35  <bitcoin-git> [bitcoin] jnewbery opened pull request #20008: [Backport] #19839 and #19842 to v0.20 (0.20...2020-09-appveyor-backport) https://github.com/bitcoin/bitcoin/pull/20008
1212020-09-24T08:41:47  *** bitcoin-git has left #bitcoin-core-dev
1222020-09-24T08:42:04  <jnewbery> wumpus: those appveyor commits fixed my issue. I've opened a PR to just backport those two commits. Thanks for your help!
1232020-09-24T08:51:00  *** andreacab has quit IRC
1242020-09-24T08:52:53  *** andreacab has joined #bitcoin-core-dev
1252020-09-24T08:57:49  *** andreacab has quit IRC
1262020-09-24T09:02:57  *** jonatack has joined #bitcoin-core-dev
1272020-09-24T09:04:25  *** kexkey has quit IRC
1282020-09-24T09:05:05  *** AaronvanW has quit IRC
1292020-09-24T09:05:31  *** AaronvanW has joined #bitcoin-core-dev
1302020-09-24T09:08:59  *** andreacab has joined #bitcoin-core-dev
1312020-09-24T09:09:17  *** jonatack has joined #bitcoin-core-dev
1322020-09-24T09:19:56  *** davec has quit IRC
1332020-09-24T09:21:52  *** bshum1 has joined #bitcoin-core-dev
1342020-09-24T09:34:15  *** sr_gi7 has joined #bitcoin-core-dev
1352020-09-24T09:34:39  *** sr_gi has quit IRC
1362020-09-24T09:34:39  *** sr_gi7 is now known as sr_gi
1372020-09-24T09:35:32  *** andreacab has quit IRC
1382020-09-24T09:37:45  *** andreacab has joined #bitcoin-core-dev
1392020-09-24T09:49:27  *** bitcoin-git has joined #bitcoin-core-dev
1402020-09-24T09:49:27  <bitcoin-git> [bitcoin] naumenkogs closed pull request #19843: Refactoring and minor improvement for self-advertisements (master...2020-08-refactor-advertiselocal) https://github.com/bitcoin/bitcoin/pull/19843
1412020-09-24T09:49:29  *** bitcoin-git has left #bitcoin-core-dev
1422020-09-24T09:49:47  *** bitcoin-git has joined #bitcoin-core-dev
1432020-09-24T09:49:47  <bitcoin-git> [bitcoin] naumenkogs reopened pull request #19843: Refactoring and minor improvement for self-advertisements (master...2020-08-refactor-advertiselocal) https://github.com/bitcoin/bitcoin/pull/19843
1442020-09-24T09:49:49  *** bitcoin-git has left #bitcoin-core-dev
1452020-09-24T09:54:46  *** S3RK has quit IRC
1462020-09-24T09:55:20  *** S3RK has joined #bitcoin-core-dev
1472020-09-24T09:58:03  *** S3RK has quit IRC
1482020-09-24T09:58:04  *** justinmoon has quit IRC
1492020-09-24T09:58:13  *** S3RK has joined #bitcoin-core-dev
1502020-09-24T10:00:04  *** justinmoon has joined #bitcoin-core-dev
1512020-09-24T10:05:38  *** mrostecki has joined #bitcoin-core-dev
1522020-09-24T10:10:03  *** vasild has quit IRC
1532020-09-24T10:12:05  *** vasild has joined #bitcoin-core-dev
1542020-09-24T10:18:23  *** Lonny59Schumm has joined #bitcoin-core-dev
1552020-09-24T10:20:02  *** andreacab has quit IRC
1562020-09-24T10:20:28  *** andreacab has joined #bitcoin-core-dev
1572020-09-24T10:25:13  *** andreacab has quit IRC
1582020-09-24T10:36:06  *** S3RK has quit IRC
1592020-09-24T10:36:32  *** S3RK has joined #bitcoin-core-dev
1602020-09-24T10:59:53  *** jonatack has quit IRC
1612020-09-24T11:03:30  *** Highway61 has joined #bitcoin-core-dev
1622020-09-24T11:07:06  *** S3RK has quit IRC
1632020-09-24T11:07:16  *** S3RK has joined #bitcoin-core-dev
1642020-09-24T11:08:19  *** S3RK has joined #bitcoin-core-dev
1652020-09-24T11:13:31  *** tralfaz has joined #bitcoin-core-dev
1662020-09-24T11:13:31  *** andreacab has joined #bitcoin-core-dev
1672020-09-24T11:13:44  *** S3RK has quit IRC
1682020-09-24T11:15:23  *** davterra has quit IRC
1692020-09-24T11:28:09  *** andreacab has quit IRC
1702020-09-24T11:28:39  *** andreacab has joined #bitcoin-core-dev
1712020-09-24T11:30:44  *** Lonny59Schumm has quit IRC
1722020-09-24T11:31:46  *** MrPaz has joined #bitcoin-core-dev
1732020-09-24T11:34:18  *** andreacab has quit IRC
1742020-09-24T11:34:44  *** andreacab has joined #bitcoin-core-dev
1752020-09-24T11:39:19  *** andreacab has quit IRC
1762020-09-24T11:46:44  *** mrostecki has quit IRC
1772020-09-24T11:49:52  *** jonatack has joined #bitcoin-core-dev
1782020-09-24T11:52:21  *** andreacab has joined #bitcoin-core-dev
1792020-09-24T11:56:04  *** andreacab has quit IRC
1802020-09-24T11:56:30  *** andreacab has joined #bitcoin-core-dev
1812020-09-24T11:57:29  <wumpus> jnewbery: great! yes, seems good to backport them separately and get them in first
1822020-09-24T12:00:02  *** bshum1 has quit IRC
1832020-09-24T12:00:56  *** mrostecki has joined #bitcoin-core-dev
1842020-09-24T12:01:29  *** andreacab has quit IRC
1852020-09-24T12:08:15  *** bitcoin-git has joined #bitcoin-core-dev
1862020-09-24T12:08:16  <bitcoin-git> [bitcoin] laanwj pushed 3 commits to 0.20: https://github.com/bitcoin/bitcoin/compare/30926997fa15...80aa83aa4064
1872020-09-24T12:08:17  <bitcoin-git> bitcoin/0.20 ad99777 Aaron Clauson: Set appveyor vm version to previous Visual Studio 2019 release.
1882020-09-24T12:08:18  <bitcoin-git> bitcoin/0.20 498b7cb Aaron Clauson: Update the vcpkg checkout commit ID in appveyor config.
1892020-09-24T12:08:18  <bitcoin-git> bitcoin/0.20 80aa83a Wladimir J. van der Laan: Merge #20008: [Backport] #19839 and #19842 to v0.20
1902020-09-24T12:08:20  *** bitcoin-git has left #bitcoin-core-dev
1912020-09-24T12:08:35  *** bitcoin-git has joined #bitcoin-core-dev
1922020-09-24T12:08:35  <bitcoin-git> [bitcoin] laanwj merged pull request #20008: [Backport] #19839 and #19842 to v0.20 (0.20...2020-09-appveyor-backport) https://github.com/bitcoin/bitcoin/pull/20008
1932020-09-24T12:08:36  *** bitcoin-git has left #bitcoin-core-dev
1942020-09-24T12:21:57  *** jackalope has joined #bitcoin-core-dev
1952020-09-24T12:23:16  *** bitcoin-git has joined #bitcoin-core-dev
1962020-09-24T12:23:16  <bitcoin-git> [bitcoin] jnewbery closed pull request #19759: [doc] Struct members should have m_ prefix (master...2020-08-struct-members) https://github.com/bitcoin/bitcoin/pull/19759
1972020-09-24T12:23:17  *** bitcoin-git has left #bitcoin-core-dev
1982020-09-24T12:33:30  *** jonatack has quit IRC
1992020-09-24T12:36:45  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2002020-09-24T13:06:24  *** andreacab has joined #bitcoin-core-dev
2012020-09-24T13:08:41  *** andreaca_ has joined #bitcoin-core-dev
2022020-09-24T13:11:14  *** andreaca_ has quit IRC
2032020-09-24T13:12:25  *** andreacab has quit IRC
2042020-09-24T13:30:27  *** jackalope has quit IRC
2052020-09-24T13:30:44  *** gatox has joined #bitcoin-core-dev
2062020-09-24T13:39:05  *** Guyver2 has joined #bitcoin-core-dev
2072020-09-24T13:40:37  *** S3RK has joined #bitcoin-core-dev
2082020-09-24T13:41:17  *** S3RK_ has joined #bitcoin-core-dev
2092020-09-24T13:45:12  *** S3RK has quit IRC
2102020-09-24T13:49:13  *** opsec_x12 has quit IRC
2112020-09-24T13:51:09  *** andreacab has joined #bitcoin-core-dev
2122020-09-24T13:57:50  *** DeanGuss has quit IRC
2132020-09-24T13:58:54  *** S3RK_ has quit IRC
2142020-09-24T14:01:46  *** davterra has joined #bitcoin-core-dev
2152020-09-24T14:04:23  *** tralfaz has quit IRC
2162020-09-24T14:05:05  *** tralfaz has joined #bitcoin-core-dev
2172020-09-24T14:05:06  *** Landryl has quit IRC
2182020-09-24T14:05:43  *** davterra has quit IRC
2192020-09-24T14:12:53  *** Landryl has joined #bitcoin-core-dev
2202020-09-24T14:17:14  *** S3RK has joined #bitcoin-core-dev
2212020-09-24T14:21:39  *** S3RK has quit IRC
2222020-09-24T14:25:01  *** kexkey has joined #bitcoin-core-dev
2232020-09-24T14:25:03  *** davec has joined #bitcoin-core-dev
2242020-09-24T14:27:42  *** DeanGuss has joined #bitcoin-core-dev
2252020-09-24T14:31:34  *** tralfaz is now known as davterra
2262020-09-24T14:33:08  *** S3RK has joined #bitcoin-core-dev
2272020-09-24T14:38:01  *** S3RK has quit IRC
2282020-09-24T14:38:36  *** DeanGuss has quit IRC
2292020-09-24T14:39:01  *** DeanGuss has joined #bitcoin-core-dev
2302020-09-24T14:39:32  *** DeanGuss has quit IRC
2312020-09-24T14:41:02  *** DeanGuss has joined #bitcoin-core-dev
2322020-09-24T14:42:15  *** harding has quit IRC
2332020-09-24T14:43:07  *** harding has joined #bitcoin-core-dev
2342020-09-24T14:47:13  *** Talkless has joined #bitcoin-core-dev
2352020-09-24T14:49:13  *** S3RK has joined #bitcoin-core-dev
2362020-09-24T14:49:37  *** andreacab has quit IRC
2372020-09-24T14:50:04  *** andreacab has joined #bitcoin-core-dev
2382020-09-24T14:52:15  *** davterra has quit IRC
2392020-09-24T14:52:52  *** davterra has joined #bitcoin-core-dev
2402020-09-24T14:53:44  *** S3RK has quit IRC
2412020-09-24T14:54:37  *** andreacab has quit IRC
2422020-09-24T14:54:51  *** andreacab has joined #bitcoin-core-dev
2432020-09-24T14:56:40  *** promag has joined #bitcoin-core-dev
2442020-09-24T15:00:02  *** gatox has quit IRC
2452020-09-24T15:10:58  *** Talkless has quit IRC
2462020-09-24T15:22:03  *** erwin_bullet has joined #bitcoin-core-dev
2472020-09-24T15:22:04  *** tralfaz has joined #bitcoin-core-dev
2482020-09-24T15:25:03  *** davterra has quit IRC
2492020-09-24T15:27:23  *** mrostecki has quit IRC
2502020-09-24T15:32:24  *** tralfaz is now known as davterra
2512020-09-24T15:37:15  *** andreacab has quit IRC
2522020-09-24T15:37:41  *** andreacab has joined #bitcoin-core-dev
2532020-09-24T15:42:31  *** andreacab has quit IRC
2542020-09-24T15:44:31  *** wumpus has quit IRC
2552020-09-24T15:44:37  *** dr-orlovsky has quit IRC
2562020-09-24T15:45:53  *** dr-orlovsky has joined #bitcoin-core-dev
2572020-09-24T15:52:36  *** andreacab has joined #bitcoin-core-dev
2582020-09-24T15:57:58  *** promag has quit IRC
2592020-09-24T16:01:01  *** mrostecki has joined #bitcoin-core-dev
2602020-09-24T16:11:03  *** davterra has quit IRC
2612020-09-24T16:11:45  *** davterra has joined #bitcoin-core-dev
2622020-09-24T16:11:46  *** owowo has quit IRC
2632020-09-24T16:16:00  *** owowo has joined #bitcoin-core-dev
2642020-09-24T16:16:11  *** andreacab has quit IRC
2652020-09-24T16:16:37  *** andreacab has joined #bitcoin-core-dev
2662020-09-24T16:16:56  *** S3RK has joined #bitcoin-core-dev
2672020-09-24T16:20:32  *** justanotheruser has joined #bitcoin-core-dev
2682020-09-24T16:21:09  *** andreacab has quit IRC
2692020-09-24T16:21:22  *** S3RK has quit IRC
2702020-09-24T16:33:17  *** S3RK has joined #bitcoin-core-dev
2712020-09-24T16:37:20  *** andreacab has joined #bitcoin-core-dev
2722020-09-24T16:37:34  *** S3RK has quit IRC
2732020-09-24T16:37:43  *** braydonf has quit IRC
2742020-09-24T16:47:37  *** andreacab has quit IRC
2752020-09-24T16:48:03  *** andreacab has joined #bitcoin-core-dev
2762020-09-24T16:50:43  *** braydonf has joined #bitcoin-core-dev
2772020-09-24T16:50:51  *** S3RK has joined #bitcoin-core-dev
2782020-09-24T16:51:05  *** Victorsueca has quit IRC
2792020-09-24T16:52:49  *** andreacab has quit IRC
2802020-09-24T16:55:39  *** S3RK has quit IRC
2812020-09-24T16:56:53  *** S3RK has joined #bitcoin-core-dev
2822020-09-24T17:01:25  *** S3RK has quit IRC
2832020-09-24T17:03:15  *** andreacab has joined #bitcoin-core-dev
2842020-09-24T17:07:56  *** andreacab has quit IRC
2852020-09-24T17:08:22  *** andreacab has joined #bitcoin-core-dev
2862020-09-24T17:09:47  *** filchef has joined #bitcoin-core-dev
2872020-09-24T17:12:56  *** S3RK has joined #bitcoin-core-dev
2882020-09-24T17:13:05  *** andreacab has quit IRC
2892020-09-24T17:17:43  *** S3RK has quit IRC
2902020-09-24T17:32:05  *** jonatack has joined #bitcoin-core-dev
2912020-09-24T17:48:39  *** DeanGuss has quit IRC
2922020-09-24T17:49:07  *** DeanGuss has joined #bitcoin-core-dev
2932020-09-24T17:57:01  *** troygiorshev has joined #bitcoin-core-dev
2942020-09-24T17:57:50  *** DeanGuss has quit IRC
2952020-09-24T18:00:02  *** erwin_bullet has quit IRC
2962020-09-24T18:10:00  *** DeanGuss has joined #bitcoin-core-dev
2972020-09-24T18:11:33  *** watchtower has joined #bitcoin-core-dev
2982020-09-24T18:13:33  *** DeanGuss has quit IRC
2992020-09-24T18:14:16  *** DeanGuss has joined #bitcoin-core-dev
3002020-09-24T18:14:34  *** watchtower has quit IRC
3012020-09-24T18:20:51  *** m4v1 has joined #bitcoin-core-dev
3022020-09-24T18:30:08  *** opsec_x12 has joined #bitcoin-core-dev
3032020-09-24T18:37:00  <luke-jr> sipa: a ton of CNetAddr stuff is changed
3042020-09-24T18:38:40  <sipa> luke-jr: yes, i was talking about the 0.20.1 codebase fwiw
3052020-09-24T18:38:49  <sipa> i think it's the same in master though
3062020-09-24T18:39:43  <luke-jr> _ZN26PartiallySignedTransaction11UnserializeI11CDataStreamEEvRT_
3072020-09-24T18:40:04  <luke-jr> this seems to be the worst of it
3082020-09-24T18:40:52  <sipa> that's a function you see changed with the gcc patch?
3092020-09-24T18:42:05  <luke-jr> yes
3102020-09-24T18:42:35  <luke-jr> is there a good way to get objdump disassembly without addresses and similar diff-complicating stuff?
3112020-09-24T18:45:58  <luke-jr> https://dpaste.com/23HQPNBF4
3122020-09-24T18:47:26  <luke-jr> list of changed code symbols: https://dpaste.com/GU4GPSPB8
3132020-09-24T18:52:03  *** andreacab has joined #bitcoin-core-dev
3142020-09-24T19:00:09  <MarcoFalke> (been offline from IRC for two weeks. If there are any questions I missed, let me know)
3152020-09-24T19:00:16  <MarcoFalke> Also meeting time?
3162020-09-24T19:00:22  <jonasschnelli> jep
3172020-09-24T19:00:43  *** mrostecki has quit IRC
3182020-09-24T19:01:10  <sipa> hi
3192020-09-24T19:01:15  *** wumpus has joined #bitcoin-core-dev
3202020-09-24T19:01:17  <sipa> MarcoFalke: wb
3212020-09-24T19:02:20  <MarcoFalke> sipa: The qa-assets can be cloned with --depth=1, but it shouldn't make a difference right now, as all files were append only
3222020-09-24T19:02:30  <MarcoFalke> Might change when we start deleting fuzz seeds
3232020-09-24T19:02:37  <wumpus> #startmeeting
3242020-09-24T19:02:37  <lightningbot> Meeting started Thu Sep 24 19:02:37 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3252020-09-24T19:02:37  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3262020-09-24T19:02:41  <jonasschnelli> hi
3272020-09-24T19:02:43  <jonatack> hi
3282020-09-24T19:02:43  <MarcoFalke> hi
3292020-09-24T19:02:45  <hebasto> hi
3302020-09-24T19:02:46  <amiti> hi
3312020-09-24T19:02:50  <fjahr> hi
3322020-09-24T19:02:51  <luke-jr> hi
3332020-09-24T19:02:53  <sipa> hi
3342020-09-24T19:02:53  <achow101> hi
3352020-09-24T19:03:09  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james
3362020-09-24T19:03:11  <wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
3372020-09-24T19:03:28  <meshcollider> hi
3382020-09-24T19:03:49  <jnewbery> hi
3392020-09-24T19:03:58  <wumpus> one proposed topic: what sipa just said (will have to look up in the log what :-)
3402020-09-24T19:04:18  <sipa> wumpus: #20005
3412020-09-24T19:04:19  <gribble> https://github.com/bitcoin/bitcoin/issues/20005 | memcmp with constants that contain zero bytes are broken in GCC · Issue #20005 · bitcoin/bitcoin · GitHub
3422020-09-24T19:04:38  <luke-jr> https://dpaste.com/GU4GPSPB8 <-- affected symbols in bitcoind
3432020-09-24T19:04:42  <jeremyrubin> hi
3442020-09-24T19:04:42  <wumpus> I see
3452020-09-24T19:05:11  <sipa> yeah i just wanted to draw attention to this potentially very scary bug
3462020-09-24T19:05:26  <wumpus> how did they manage to break such a basic library function
3472020-09-24T19:05:30  <kanzure> hi
3482020-09-24T19:05:38  <luke-jr> wumpus: they turned it into strcmp sometimes it looks like
3492020-09-24T19:05:43  <sipa> wumpus: it's not a libc bug, it's bug in gcc's implementation of __builtin_memcmp
3502020-09-24T19:05:50  <luke-jr> at least the consensus code seems to have dodged it
3512020-09-24T19:06:08  <sipa> but otherwise yes, this is really concerning
3522020-09-24T19:06:20  <sipa> i believe none of our gitian builds are affected, as we use older GCCs
3532020-09-24T19:06:27  <sipa> can someone verify that?
3542020-09-24T19:06:32  <wumpus> that's at least good to know, let me see
3552020-09-24T19:06:50  <luke-jr> macOS build should use LLVM IIRC
3562020-09-24T19:06:57  <sipa> luke-jr: indeed
3572020-09-24T19:07:06  <jeremyrubin> sipa: is this a generaly class of bugs do you reckon or pretty specific to memcmp? should we be auditing all builtins?
3582020-09-24T19:07:10  <MarcoFalke> sipa: Gitian should use 7 and 8
3592020-09-24T19:07:11  <luke-jr> I *assume* LLVM didn't reimplement this bug
3602020-09-24T19:07:13  <wumpus> gcc 8 it seems
3612020-09-24T19:07:46  <sipa> jeremyrubin: i don't think we have the manpower to do actual auditing of all of gcc's builtins (and other potential bugs), nor is that our job
3622020-09-24T19:07:50  <jonasschnelli> bionic uses gcc 7, right?
3632020-09-24T19:08:06  <luke-jr> jonasschnelli: yes
3642020-09-24T19:08:12  <wumpus> jonasschnelli: but we explicitly install 8 for some platforms
3652020-09-24T19:08:17  <luke-jr> ^
3662020-09-24T19:08:28  <sipa> jeremyrubin: i think it's important to note that while the bug was known, we stumbled upon it in the libsecp256k1 repo, in a test
3672020-09-24T19:08:48  <jonasschnelli> Ah. Yes. Arm / risc uses gcc-8
3682020-09-24T19:08:54  <luke-jr> hmm
3692020-09-24T19:08:56  <sipa> so that's kind of a sign that our processes are at least capable of catching some issues like this
3702020-09-24T19:09:06  <luke-jr> sipa: should I be concerned I *didn't* get any libsecp symbols in my comparison?
3712020-09-24T19:09:25  <wumpus> I honestly don't now how to prevent us being affected by problems like this
3722020-09-24T19:09:26  <luke-jr> or is the test only in a newer version?
3732020-09-24T19:09:26  <sipa> luke-jr: no, i think this is expected (it's in code added in a new test)
3742020-09-24T19:09:28  <wumpus> computers are broken
3752020-09-24T19:09:35  <jonasschnelli> indeed
3762020-09-24T19:10:09  <sipa> reality is often disappointing
3772020-09-24T19:10:11  <wumpus> I can understand libc bugs in some cases but this is something so low-level
3782020-09-24T19:10:40  <sipa> anyway, i think we should see what performance impact building with -fno-builtin-memcmp has
3792020-09-24T19:10:51  <wumpus> sipa: yes but only for affected compilers
3802020-09-24T19:10:58  <sipa> if that is sufficiently low, i think that's a sufficient solution - perhaps restricted to GCC 9 and 10
3812020-09-24T19:10:59  <luke-jr> sipa: that won't fix C++ afaik
3822020-09-24T19:11:06  <sipa> luke-jr: it will
3832020-09-24T19:11:29  <sipa> luke-jr: std::lexicographical_compare (in the .h file) just calls __builting_memcmp
3842020-09-24T19:11:38  <MarcoFalke> Should we also add a test that fails with gcc9/10?
3852020-09-24T19:11:39  <wumpus> I don't even care about peformance there, just add the option, it needs to be correct, if people want performance don't use a broken compiler
3862020-09-24T19:11:46  <sipa> MarcoFalke: definitely
3872020-09-24T19:11:52  <luke-jr> sipa: -fno-builtin-* doesn't affect __builtin_*
3882020-09-24T19:12:00  <sipa> luke-jr: hmm!
3892020-09-24T19:12:09  <sipa> that's a good point, let's test that
3902020-09-24T19:12:18  <wumpus> that's the important thing thoug hthat it fixes the issue, a test like MarcoFalke says makes a lot of sense
3912020-09-24T19:12:35  <luke-jr> at least GCC's docs suggest to whitelist builtins, one should use -fno-builtin and call __builtin_* directly ;)
3922020-09-24T19:13:00  <wumpus> or just fail compiling on affected compilers, they're going to backport a fix right?
3932020-09-24T19:13:09  <sipa> wumpus: yes
3942020-09-24T19:13:12  <luke-jr> wumpus: supposedly, but it looks non-trivial and they haven't yet
3952020-09-24T19:13:15  *** tralfaz has joined #bitcoin-core-dev
3962020-09-24T19:13:28  <wumpus> I'd prefer things to build at all on compilers with a broken memcmp
3972020-09-24T19:13:33  <wumpus> +not
3982020-09-24T19:13:44  <sipa> it's fixed in master, but not in any release
3992020-09-24T19:14:06  <jonatack> gcc 9.3 and 10.1 seem afficted
4002020-09-24T19:14:15  <wumpus> (whatever we end up doing, we need a test for this in configure)
4012020-09-24T19:14:18  <luke-jr> personally, I neutered my builtin memcmp to always fail (fallback to libc) and am rebuilding my system
4022020-09-24T19:14:40  <sipa> wumpus: my first thought was adding a configure test that exploits the bug... but that won't work when crosscompiling
4032020-09-24T19:14:43  <sipa> i think?
4042020-09-24T19:14:57  <luke-jr> well, crosscompiling, we can't run it
4052020-09-24T19:14:58  <wumpus> sipa: ... ugh
4062020-09-24T19:15:03  <luke-jr> why not add a sanity check? we have others
4072020-09-24T19:15:09  <sipa> unless we assume that building for the host platform is always similarly affected as the target platform
4082020-09-24T19:15:12  <wumpus> yes, you'd need to run it to figure it out right
4092020-09-24T19:15:14  <jeremyrubin> Is memcmp constexpr?
4102020-09-24T19:15:21  <jeremyrubin> Maybe it can static_assert...
4112020-09-24T19:15:26  <sipa> jeremyrubin: it's a C function constexpr is a C++ concept
4122020-09-24T19:15:29  <wumpus> holy shit this is *really* bad
4132020-09-24T19:15:41  <luke-jr> sipa: bad assumption
4142020-09-24T19:15:51  <sipa> luke-jr: yes, i think so
4152020-09-24T19:15:52  <wumpus> maybe it could expect the symbols generated or something, if it generates a call to strcpy instead?
4162020-09-24T19:16:08  <sipa> wumpus: there are no calls involved
4172020-09-24T19:16:09  <luke-jr> wumpus: it doesn't
4182020-09-24T19:16:14  <sipa> it's the autogenerated builtin code that is wrong
4192020-09-24T19:16:19  <luke-jr> wumpus: it's unrolling the memcmp
4202020-09-24T19:16:22  <wumpus> ok...
4212020-09-24T19:16:23  *** davterra has quit IRC
4222020-09-24T19:16:31  <sipa> which makes it implementation something more or less equal to strcmp rather than memcmp
4232020-09-24T19:16:52  <luke-jr> basically turns it into if (a[0] == "x" && a[1] == "x" && …)
4242020-09-24T19:17:11  <luke-jr> aiui
4252020-09-24T19:17:24  <wumpus> that's impossible to check in a platform independent way
4262020-09-24T19:17:43  *** tralfaz has quit IRC
4272020-09-24T19:17:44  <jonatack> it's unclear to me if the patch is in the gcc 10.2 release?
4282020-09-24T19:17:50  <luke-jr> jonatack: no
4292020-09-24T19:17:52  <sipa> jonatack: it is not in any release
4302020-09-24T19:18:00  <jonatack> thank you
4312020-09-24T19:18:03  <real_or_random> fwiw, this is (part of) the GCC patch that fixes this: https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/builtins.c;h=228db78f32bfdcce31e23850e878843d7a45adcc;hp=eb662112b32e5ad377d2a865d9977c64dc12cc93;hb=d5803b9876b3d11c93d1a10fabb3fbb1c4a14bd6;hpb=3e99ed65cbedf7a6c0abb9cd63c191326995fd34
4322020-09-24T19:18:21  <jeremyrubin> Could we wrap memcmp with a compile time wrapper that static asserts we aren't using a const array with a 0 byte? Not sure if you can enable-if-fu around constexpr args.
4332020-09-24T19:18:38  <real_or_random> it's hard to read but I think it's possible to deduce a few condition under which this bug can't happen
4342020-09-24T19:18:42  <sipa> jeremyrubin: that's not a solution
4352020-09-24T19:18:43  <jeremyrubin> The bug only happens when it's a const array right?
4362020-09-24T19:18:45  *** cepheus17 has joined #bitcoin-core-dev
4372020-09-24T19:19:05  <sipa> jeremyrubin: if we can identify all potentially affected code paths, we could just replace them with my_memcmp that doesn't have the bug too
4382020-09-24T19:19:31  <jeremyrubin> ah right you're worried about other stdlib calls and stuff.
4392020-09-24T19:19:37  *** cepheus17 has left #bitcoin-core-dev
4402020-09-24T19:19:37  <wumpus> but C++ also generates memcmps it's not just our own code
4412020-09-24T19:19:49  <wumpus> it's a very low-level function
4422020-09-24T19:19:52  <luke-jr> sipa: I just did that? :P
4432020-09-24T19:20:02  <sipa> right - "all code paths" also contains std::lexicographical_compare and a few other things
4442020-09-24T19:20:10  <sipa> luke-jr: right, but not in a guaranteed automated way
4452020-09-24T19:20:23  <sipa> luke-jr: it's a really useful way of finding potential issues now, though
4462020-09-24T19:20:26  <sipa> thanks for that
4472020-09-24T19:21:29  <sipa> i've tried making configure detect the version of GCC, and so far been unsuccesful
4482020-09-24T19:22:03  <sipa> my google-fu led me to 9-year old stackoverflow posts with comments "ah yes, that doesn't work anymore, let's just delete that functionality" from the m4 gcc scripts
4492020-09-24T19:22:09  <sipa> (though i'm sure people with more autoconf skills can do better)
4502020-09-24T19:22:11  <luke-jr> >_<
4512020-09-24T19:22:28  <sipa> the idea is that in general you should test for compiler features, rather than exact versions
4522020-09-24T19:22:36  <sipa> which is absolutely true, except for bug workarounds :p
4532020-09-24T19:22:37  <wumpus> and as soon as the patch is backported to gcc 9 and 10 it will become more difficult too
4542020-09-24T19:22:38  <luke-jr> sipa: ideally, yes
4552020-09-24T19:22:52  <luke-jr> sipa: even for bug workarounds, you can't use the version number to see that my GCC is patched ;)
4562020-09-24T19:23:02  <sipa> that's true, but it's a safe superset
4572020-09-24T19:23:07  <wumpus> worse, some distributions might backport the single patch without changing the version number
4582020-09-24T19:23:25  <wumpus> sure, it dpeends on what it does in that case
4592020-09-24T19:23:26  <sipa> anyway, what's the plan?
4602020-09-24T19:23:33  <wumpus> if it only passes an extra command line flag it's ok
4612020-09-24T19:23:35  <sipa> i think the first thing to do is add a unit test that catches the bug
4622020-09-24T19:23:54  <luke-jr> sipa: why not sanity test?
4632020-09-24T19:23:55  <sipa> though we also need to make sure it doesn't become an "expected failure" thing that people ignore
4642020-09-24T19:23:56  <wumpus> but it shouldn't fail the build for versions that have been fixed
4652020-09-24T19:24:08  <sipa> luke-jr: that's a good point
4662020-09-24T19:24:24  <wumpus> a sanity check makes sense
4672020-09-24T19:24:43  *** tralfaz has joined #bitcoin-core-dev
4682020-09-24T19:25:01  <luke-jr> the GCC bug tracker has a reduced test (note the first test *didn't* fail on my unpatched GCC)
4692020-09-24T19:25:02  *** tralfaz is now known as davterra
4702020-09-24T19:25:03  *** andreacab has quit IRC
4712020-09-24T19:25:29  <sipa> luke-jr: yeah, it seems the cases you need to catch it differ slightly between gcc 9 and 10
4722020-09-24T19:25:49  <luke-jr> hmm
4732020-09-24T19:26:01  <luke-jr> I wonder if that means different code could be affected by GCC 9?
4742020-09-24T19:26:09  <luke-jr> or is GCC 9's affected a strict subset of GCC 10's?
4752020-09-24T19:26:15  <sipa> we also should figure out if -fno-builtin-memcmp fixes std::lexicographical_compare
4762020-09-24T19:26:30  *** mrostecki has joined #bitcoin-core-dev
4772020-09-24T19:26:33  <luke-jr> I very doubt it does
4782020-09-24T19:26:37  <sipa> luke-jr: i don't know
4792020-09-24T19:27:09  <sipa> i don't want to monopolize the meeting with this; we can also continue discussion on #20005
4802020-09-24T19:27:11  <gribble> https://github.com/bitcoin/bitcoin/issues/20005 | memcmp with constants that contain zero bytes are broken in GCC · Issue #20005 · bitcoin/bitcoin · GitHub
4812020-09-24T19:27:31  <sipa> but i think this is deserves some priority
4822020-09-24T19:27:32  <wumpus> we don't have any proposed topics at least
4832020-09-24T19:27:58  <wumpus> but we can go to high priority for review if this topic is finished
4842020-09-24T19:28:54  <wumpus> #topic High priority for review
4852020-09-24T19:29:07  <wumpus> https://github.com/bitcoin/bitcoin/projects/8  13 blockers, 1 bugfix, 2 chasing concept ACK
4862020-09-24T19:29:14  <real_or_random> i'm somewhat curious to add a patch to GCC that makes it emit a message if it applies this optimization wrongly. that may be possible with some effort given that we have the GCC patch that fixes the issue. but not sure if I'll find time
4872020-09-24T19:29:42  <sipa> real_or_random: luke modified his compiler with the patch, and then tried to see which symbols differ before and after
4882020-09-24T19:29:59  <sipa> (we can continue after the high priority for review topic)
4892020-09-24T19:30:03  <real_or_random> sipa: oh I missed that, cool
4902020-09-24T19:30:06  <real_or_random> yes
4912020-09-24T19:30:59  <wumpus> patching gcc is not a solution that we can rely on in general as most people don't build their own gcc
4922020-09-24T19:31:49  <luke-jr> right, I was just doing it to quickly audit what was affected
4932020-09-24T19:31:58  <wumpus> sure, for that it's a great way
4942020-09-24T19:32:16  <luke-jr> sipa: btw, I think it's using __builtin_memcmp for std::equal or == in PSBT stuff?
4952020-09-24T19:33:13  <wumpus> nothing to discuss about high priority for review PRs?
4962020-09-24T19:33:20  <sipa> i guess not...
4972020-09-24T19:33:23  <luke-jr> pls review rwconf :P
4982020-09-24T19:33:32  <jonatack> high-priority: #19845 might be close
4992020-09-24T19:33:35  <gribble> https://github.com/bitcoin/bitcoin/issues/19845 | net: CNetAddr: add support to (un)serialize as ADDRv2 by vasild · Pull Request #19845 · bitcoin/bitcoin · GitHub
5002020-09-24T19:33:53  <jonatack> was good to see signet get in this week
5012020-09-24T19:34:08  <sipa> indeed
5022020-09-24T19:34:47  <luke-jr> wumpus: oh, we could build with -O1 ?
5032020-09-24T19:35:05  <wumpus> yes
5042020-09-24T19:35:14  * luke-jr wonders how -O1 works but -fno-builtin-memcmp doesn't
5052020-09-24T19:35:34  <MarcoFalke> Doesn't that make IBD take twice as long?
5062020-09-24T19:35:40  <wumpus> probably
5072020-09-24T19:35:47  <wumpus> still better than broken builtins though
5082020-09-24T19:35:50  <MarcoFalke> Might be better to refuse to start with the sanity check
5092020-09-24T19:35:50  <luke-jr> maybe there's some more granular thing we can disable
5102020-09-24T19:35:59  <luke-jr> MarcoFalke: both ☺
5112020-09-24T19:36:06  <sipa> luke-jr: could you build with -fno-builtin-memcmp without the gcc patch, and then (for the affected symbols from your previous list) check if which ones become equal to the fixed gcc output?
5122020-09-24T19:37:12  <luke-jr> sipa: I don't have the unpatched compiler anymore :x
5132020-09-24T19:37:29  <luke-jr> on an x86 server, however, -fno-builtin-memcmp did not fix the bug
5142020-09-24T19:37:36  <luke-jr> for    int x= __builtin_memcmp (a, "\0\0\0\0", 4);
5152020-09-24T19:38:00  <sipa> sure, but we never call __builtin_memcmp directly from our code
5162020-09-24T19:38:49  <wumpus> speaking of that, what about other dependency libraries that can be assumed to have been built with the broken compiler
5172020-09-24T19:39:03  <wumpus> boost, libupnp, libevent ...
5182020-09-24T19:39:24  <luke-jr> we can't fix everything
5192020-09-24T19:39:35  <elichai2> wumpus: is it even remotely possible to check what compiler compiled an already compiled library?
5202020-09-24T19:39:35  <wumpus> no, we can't
5212020-09-24T19:39:47  <sipa> doesn't mean we can't work around it
5222020-09-24T19:39:49  <luke-jr> I suppose that's an argument for just the sanity check, and not trying to workaround it
5232020-09-24T19:39:50  <wumpus> elichai2: not in gneral
5242020-09-24T19:40:35  <sipa> like just not permitting building with known-to-be-affected compilers, which at least in some cases will avoid the situation where dependencies are built with the same thing
5252020-09-24T19:40:51  <wumpus> sipa: right
5262020-09-24T19:40:59  <sipa> but... if your system itself has bugs introduced by this, i think there is very little we can do about it
5272020-09-24T19:41:15  <wumpus> for many distributions at least, the dependencies will have been built with the same gcc/g++ that is available
5282020-09-24T19:42:20  <sipa> i believe my python3 binary is built with GCC 9.3
5292020-09-24T19:42:30  <sipa> $ strings python3.8 | fgrep GCC
5302020-09-24T19:42:30  <sipa> [GCC 9.3.0]
5312020-09-24T19:45:18  <jonatack> luke-jr: did the tests in the final patch fail on your unpatched gcc?
5322020-09-24T19:45:42  <luke-jr> didn't try
5332020-09-24T19:46:49  <wumpus> I'm going to close the meeting, can continue this discussion afterwards and we're out of topics
5342020-09-24T19:46:51  <wumpus> #endmeeting
5352020-09-24T19:46:51  <lightningbot> Meeting ended Thu Sep 24 19:46:51 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
5362020-09-24T19:46:51  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-24-19.02.html
5372020-09-24T19:46:51  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-24-19.02.txt
5382020-09-24T19:46:51  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-24-19.02.log.html
5392020-09-24T19:46:56  <sipa> sg
5402020-09-24T19:47:22  <luke-jr> I can't find a flag that makes -O1 fail :/
5412020-09-24T19:47:35  <elichai2> unless both of the sides are constants I can't manage to get `std::lexicographical_compare` to *not* produce a `memcmp` call.
5422020-09-24T19:48:11  *** belcher has quit IRC
5432020-09-24T19:48:37  <sipa> elichai2: what if one side is a constant that starts with a 0 byte?
5442020-09-24T19:48:49  <sipa> or the length is restricted to at most 3 bytes
5452020-09-24T19:49:03  <elichai2> sipa: here: https://godbolt.org/z/65WWPf
5462020-09-24T19:49:17  <elichai2> even 2 bytes, where in compile time it can see it's 2 bytes, it still produces a memcmp
5472020-09-24T19:50:55  <elichai2> only when the array is 1 byte it doesn't call to memcmp, and instead it generates a `cmp     BYTE PTR [rdi], 0` instruction (compare with zero(because my other array is zero))
5482020-09-24T19:51:12  *** Chris_Stewart_5 has quit IRC
5492020-09-24T19:51:35  <sipa> and if you take the same code but with memcmp instead of std::lexicographical_compare, it does avoid the memcmp call
5502020-09-24T19:51:52  <roconnor> luke-jr: my understanding is that it isn't quite that builtin_memcmp is broken but an optimization surrounding it that is invoked at level -O2 is broken.
5512020-09-24T19:52:47  <sipa> i changed the 0.20.1 source code to replace IsIPv4() with "return ip[0] == 0;" (which is what I understand the bug would turn it into now)... the tests fail
5522020-09-24T19:53:01  <sipa> so whatever it's doing, it's not doing that, or we'd have caught it
5532020-09-24T19:53:23  *** mrostecki has quit IRC
5542020-09-24T19:54:10  <elichai2> sipa: yes. if I just replace with `memcmp` it produces bad code
5552020-09-24T19:54:19  <elichai2> https://godbolt.org/z/a9Wf11
5562020-09-24T19:57:10  <elichai2> I think it ***might*** be because `lexicographical_compare` gets both start and end iterators of both sides, then it sees they're the same size, so it replaces with memcmp but it might be the same round where they replace memcmp so it doesn't do this deduction again, ***maybe***
5572020-09-24T19:57:37  <meshcollider> Tomorrow is the wallet meeting but I won't be able to make it. So either someone else might want to host, or since it has been quiet the last few meetings we might just cancel it tomorrow
5582020-09-24T19:58:15  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5592020-09-24T19:59:31  <luke-jr> https://dpaste.com/GT7VUNFKV <-- _ZNK8CNetAddr6IsIPv4Ev diff
5602020-09-24T20:00:17  <elichai2> luke-jr: is this MIPS?
5612020-09-24T20:00:25  <luke-jr> elichai2: PPC
5622020-09-24T20:00:56  <luke-jr> sorry, I guess it's not quite familiar to most
5632020-09-24T20:02:35  <luke-jr> https://dpaste.com/9E7Z9NNZ7 <-- full assembly dump of it
5642020-09-24T20:03:21  <sipa> if i change IsIPv4() to memcmp(...) > 0 (rather than == 0), gcc 9.3 emits broken code
5652020-09-24T20:03:57  <sipa> i'm beginning to suspect that (in)equality checks use a different optimization path that isn't affected
5662020-09-24T20:05:19  <sipa> which if true would be good news, as it means automatically generated operator== code isn't affected either (and there exists no automatically generated < <= >= >)
5672020-09-24T20:06:37  <sipa> != also doesn't seem affected
5682020-09-24T20:06:38  <gribble> Error: "=" is not a valid command.
5692020-09-24T20:06:49  <sipa> stupid bot
5702020-09-24T20:10:16  <elichai2> sipa: I also can't manage to trigger this in `std::equal`
5712020-09-24T20:11:32  <jonatack> meshcollider: thanks for the heads up. i guess we'll see who is around.
5722020-09-24T20:11:58  <elichai2> (although unlike lexicographical_compare std::equal does optimize nicely)
5732020-09-24T20:14:18  <elichai2> damn it
5742020-09-24T20:14:26  <elichai2> it also happens with lexicographical_compare
5752020-09-24T20:15:13  <elichai2> if you replace the reference with a copy it happens, you can play with the optimization level and see the output changes: https://godbolt.org/z/vxEo8d
5762020-09-24T20:22:13  *** andreacab has joined #bitcoin-core-dev
5772020-09-24T20:24:47  *** owowo has quit IRC
5782020-09-24T20:25:46  *** filchef has quit IRC
5792020-09-24T20:29:26  *** owowo has joined #bitcoin-core-dev
5802020-09-24T20:33:12  <elichai2> lol `base_uint` in arith_uint256.h seems to have dodged the bullet by pure luck https://github.com/bitcoin/bitcoin/blob/master/src/arith_uint256.h#L217-L222
5812020-09-24T20:33:24  <elichai2> (actually, it's really NOT funny)
5822020-09-24T20:36:10  <roconnor> uint256.h doesn't compare with a static array, so it should be fine right?
5832020-09-24T20:36:28  <sipa> roconnor: it could be a compile-time known value in some cases
5842020-09-24T20:36:33  <elichai2> isn't max PoW static?
5852020-09-24T20:36:58  <roconnor> fair.
5862020-09-24T20:37:29  <sipa> i don't know if being a compile-time known constant it enough to trigger it; maybe it actually has to be a comparison with a constant
5872020-09-24T20:37:40  <sipa> *compile-time-known value
5882020-09-24T20:37:57  <elichai2> I hate this
5892020-09-24T20:39:12  <sipa> elichai2: great find
5902020-09-24T20:39:18  <roconnor> It has to be a value that GCC's c_getstr is able to figure out object byte representation for from the source code, however c_getstr works.
5912020-09-24T20:40:26  <sipa> elichai2: so, we learn that -fno-builtin-memcmp is not enough
5922020-09-24T20:40:35  <elichai2> yes :/
5932020-09-24T20:41:06  <sipa> it should be possible to find the subset of functions in STL that are affected by this
5942020-09-24T20:41:33  <roconnor> rather than -fno-buildin-memcmp, we need to find a flag that disables this suite of optimizations :/
5952020-09-24T20:42:01  <elichai2> we could decide to remove *all* usages of functions comparing stuff, but even `>` gets misoptimized on some containers :(
5962020-09-24T20:43:49  <sipa> roconnor: that's a possibility too
5972020-09-24T20:44:45  <roconnor> is -O2 stand in for a series of -f flags?
5982020-09-24T20:44:58  <sipa> yes
5992020-09-24T20:45:04  <roconnor> do we know which ones?
6002020-09-24T20:46:34  <elichai2> roconnor: yes, I'm testing them now
6012020-09-24T20:46:42  <roconnor> 3>
6022020-09-24T20:46:43  <elichai2> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
6032020-09-24T20:46:45  <roconnor> oops
6042020-09-24T20:46:49  <roconnor> <3
6052020-09-24T20:47:58  <elichai2> what, when I manually turn the flags on I don't get the bug OoO
6062020-09-24T20:47:59  <sipa> i'm cloning the gcc mirror repo; it's probably not too hard to find which exact flags controls this optimization
6072020-09-24T20:48:06  *** Chris_Stewart_5 has quit IRC
6082020-09-24T20:48:25  <roconnor> elichai2: I can believe that :(
6092020-09-24T20:48:59  <roconnor> elichai2: did you turn on both the -O and -O2 flags?
6102020-09-24T20:49:39  <roconnor> or do an -O  + all the -O2 flags?
6112020-09-24T20:49:56  <elichai2> I did `-O1` + all the `-O2` flags
6122020-09-24T20:50:00  <sipa> gcc -c -Q -O3 --help=optimizers
6132020-09-24T20:50:05  <sipa> prints all the enabled flags
6142020-09-24T20:52:10  <elichai2> sipa: +1
6152020-09-24T20:52:29  *** Chris_Stewart_5 has joined #bitcoin-core-dev
6162020-09-24T20:53:12  <roconnor> gcc -c -Q -O2 --help=optimizers | grep -v disabled   ?
6172020-09-24T21:00:02  *** m4v1 has quit IRC
6182020-09-24T21:05:48  *** Guyver2 has quit IRC
6192020-09-24T21:07:32  <elichai2> first `-fno-inline` seems to solve this, but that makes sense and has hugee perf penalty
6202020-09-24T21:11:13  *** Chris_Stewart_5 has quit IRC
6212020-09-24T21:14:34  *** S3RK has joined #bitcoin-core-dev
6222020-09-24T21:15:47  *** ossifrage_ is now known as ossifrage
6232020-09-24T21:19:02  *** S3RK has quit IRC
6242020-09-24T21:21:14  <elichai2> `-O2 -fno-tree-dce -fno-tree-dominator-opts -fno-tree-fre -fno-tree-pre -fno-code-hoisting`
6252020-09-24T21:21:31  <sipa> all of those are needed? :S
6262020-09-24T21:21:36  <elichai2> looks like it
6272020-09-24T21:22:19  *** patryk has joined #bitcoin-core-dev
6282020-09-24T21:22:25  <elichai2> although some flags might imply others so it might be possible to get more granular but this sounds like an NP problem lol
6292020-09-24T21:24:09  <elichai2> ignore what I just said. with `-O2` and all the O2 flags actually disabled, if any of these 5 flags aren't disabled I get the wrong result, they all need to be disabled to get the right results
6302020-09-24T21:28:02  *** promag has joined #bitcoin-core-dev
6312020-09-24T21:29:36  <promag> who has admin role in travis?
6322020-09-24T21:29:37  <roconnor> `-O2 -fno-tree-dce -fno-tree-dominator-opts -fno-tree-fre -fno-code-hoisting` seems to do something different.
6332020-09-24T21:30:27  <elichai2> roconnor: I still get the wrong result there, through a different path it seems but still the wrong one hehe
6342020-09-24T21:30:44  <roconnor> right.  sorry, yes it still appears wrong, but with different wrong asm.
6352020-09-24T21:30:54  *** S3RK has joined #bitcoin-core-dev
6362020-09-24T21:34:49  <elichai2>  it scares me that my current default compiler in my machine is so much broken right now.
6372020-09-24T21:35:18  *** S3RK has quit IRC
6382020-09-24T21:39:11  *** kexkey has quit IRC
6392020-09-24T21:41:15  *** kexkey has joined #bitcoin-core-dev
6402020-09-24T21:42:40  *** proofofkeags has quit IRC
6412020-09-24T21:43:52  *** proofofkeags has joined #bitcoin-core-dev
6422020-09-24T21:46:54  *** S3RK has joined #bitcoin-core-dev
6432020-09-24T21:49:35  <roconnor> ... I've been scrambling to recompile my entire system with gcc 8...
6442020-09-24T21:49:47  <roconnor> I don't know if I'm being too paranoid...
6452020-09-24T21:49:59  <real_or_random> idk, this bug seems scary at first glance but maybe if the scope is indeed limited, it's just one of hundreds of bugs in GCC.
6462020-09-24T21:51:13  <roconnor> real_or_random: If I figure out that you are right that GCC's miscompiling its own string_length function, I am definitely going to recompile my system.
6472020-09-24T21:51:16  *** S3RK has quit IRC
6482020-09-24T21:51:29  *** kristapsk has joined #bitcoin-core-dev
6492020-09-24T21:51:49  <roconnor> I am not waiting for the outcome of such a mess.
6502020-09-24T21:53:02  *** S3RK has joined #bitcoin-core-dev
6512020-09-24T21:53:16  <elichai2> roconnor: I'm thinking of recompiling with clang
6522020-09-24T21:57:49  *** S3RK has quit IRC
6532020-09-24T22:08:51  *** kexkey has quit IRC
6542020-09-24T22:09:06  *** S3RK has joined #bitcoin-core-dev
6552020-09-24T22:10:23  *** vasild has quit IRC
6562020-09-24T22:10:29  *** promag has quit IRC
6572020-09-24T22:11:23  *** promag has joined #bitcoin-core-dev
6582020-09-24T22:11:56  *** vasild has joined #bitcoin-core-dev
6592020-09-24T22:12:19  *** marcoagner has quit IRC
6602020-09-24T22:13:10  *** kexkey has joined #bitcoin-core-dev
6612020-09-24T22:14:02  *** S3RK has quit IRC
6622020-09-24T22:23:26  *** shesek has joined #bitcoin-core-dev
6632020-09-24T22:23:26  *** shesek has joined #bitcoin-core-dev
6642020-09-24T22:25:10  *** S3RK has joined #bitcoin-core-dev
6652020-09-24T22:29:55  *** S3RK has quit IRC
6662020-09-24T22:39:43  *** kexkey has quit IRC
6672020-09-24T22:39:53  *** andreacab has quit IRC
6682020-09-24T22:49:10  *** kexkey has joined #bitcoin-core-dev
6692020-09-24T22:55:17  *** justanotheruser has quit IRC
6702020-09-24T22:55:43  *** justanotheruser has joined #bitcoin-core-dev
6712020-09-24T22:59:23  *** davterra has quit IRC
6722020-09-24T22:59:54  *** kexkey has quit IRC
6732020-09-24T23:00:53  *** kexkey has joined #bitcoin-core-dev
6742020-09-24T23:05:30  *** kexkey has quit IRC
6752020-09-24T23:05:58  *** go11111111111 has quit IRC
6762020-09-24T23:06:51  *** troygiorshev has quit IRC
6772020-09-24T23:30:06  *** kexkey has joined #bitcoin-core-dev
6782020-09-24T23:49:51  <luke-jr> roconnor: I've been rebuilding my system as well, but with GCC 9 patched to never use the builtin memcmp
6792020-09-24T23:50:27  <luke-jr> real_or_random: it's a bug that's higher-than-average risk to create security vulnerabilities
6802020-09-24T23:51:01  <luke-jr> roconnor: real_or_random: what's this about string_length func?
6812020-09-24T23:55:47  *** kexkey has quit IRC