< bitcoin-git> [bitcoin] mjdietzx opened pull request #20276: test: run mempool_expiry.py even with wallet disabled (master...mempool-expiry-miniwallet) https://github.com/bitcoin/bitcoin/pull/20276
< bitcoin-git> [bitcoin] ariard opened pull request #20277: p2p: Do not resolve orphans during IBD and extend p2p_ibd_txrelay.py coverage (master...2020-10-ibd-txrelay) https://github.com/bitcoin/bitcoin/pull/20277
< wumpus> luke-jr: still the same as on github: add a platform specific override that changes the expectation for .plt to 'RW ' on power*
< wumpus> it's expected so it's fine to change the script but not for all architectures
< luke-jr> wumpus: ok
< wumpus> I can take a look at fixing the script but not in the coming days
< wumpus> maybe something like: - call `readelf -h <executable>`, parse out the 'Machine:' part - match that on what is returned for power64 (I don't know) -if so change the .plt* sections in the expected array to 'RW ' from 'R E'
< wumpus> "Machine: PowerPC64"
< luke-jr> right
< luke-jr> probably no rush since it slipped 0.21 anyway
< wumpus> well getting this in early for the 0.22 cycle would be good, at least it's finaly in then and not something that needs to be considered last minute every time :)
< luke-jr> looks like fanquake insists on an answer to a question I don't have answers to, so no clue how to even proceed anyway
< fanquake> luke-jr: which question
< luke-jr> fanquake: why 970
< luke-jr> the usual way to compare two archs in GCC doesn't work for PPC for some reason, so I have no idea
< luke-jr> right, that question
< fanquake> Carls questions seemed reasonable, and it was unclear given you hadn't responded. I'm not sure no-response is the way forward. If you don't know why you're making that change, you could still respond to him.
< luke-jr> it's not a change.. it's the first time we support ppc64 at all O.o
< fanquake> Right. Well in any case, leaving him answer-less is just confusing. It's unclear if you missed it, forgot to respond, ignored it etc.
< luke-jr> ok, so … I basically said the same thing (I don't know)
< fanquake> Cool, thanks
< wumpus> from what I've heard he's not the only one with tha question, more prople have concerns about that
< luke-jr> I mean, the 970 was released in 2002..
< wumpus> (I don't know the details, I'm not sure if the problem is whether the setting is too new or too old)
< wumpus> targeting Talos seems most important
< luke-jr> I think I originally had -mcpu=power9 for both
< luke-jr> but someone complained that was too new
< luke-jr> it's not like we can't change it later
< wumpus> what do common linux distros target?
< luke-jr> not sure; I think a few have recently dropped BE entirely
< luke-jr> dunno why we can't just do 970 and if someone complains try changing it to whatever they need it to be :x
< luke-jr> don't let perfect be enemy of good or whatever :P
< wumpus> I haven't really followed it in detail (I will as soon as someone sends me a POWER9 machine :-) ), but it depends on what dongcarl's concerns really are
< wumpus> in any case fanquake's remark is valid: you really need to respond to review comments even if you disagree with them, otherwise it's at the least unclear if you missed them
< wumpus> I don't have any particular opinion on what chips to support here, I just like build system changes to be uncontroversial :)
< wumpus> ofc, it's clear there's not that much gain to supporting 2002 chips, practally, even high end 2008 chips have a hard time running a validating bitcoin node
< wumpus> I do also agree it's a decision that can be easily changed later
< wumpus> would have to do some more research: what is the magnitude of the performance differences on a Talos between compiling for the different targets? is there more than a performance difference between compiling for power9 or 970? say, security extensions
< sipa> luke-jr: do you have thr means to say benchmark a reindex-chainstate on a build with -mcpu=970 vs -mcpu=power9?
< sipa> !jinx
< gribble> Error: "jinx" is not a valid command.
< wumpus> apparently in modern compilers you can also build without a .plt section at all with -fno-plt (no, not a serious suggestion to work around a python script issue, though I'm not quite sure what are the drawbacks)
< bitcoin-git> [bitcoin] hebasto closed pull request #20274: util: Drop redundant NDEBUG check (master...201030-ndebug) https://github.com/bitcoin/bitcoin/pull/20274
< bitcoin-git> [bitcoin] vasild closed pull request #20272: Add missing thread safety annotations (master...add_missing_tsa) https://github.com/bitcoin/bitcoin/pull/20272
< luke-jr> sipa: no, I don't run BE
< luke-jr> [04:49:40] <narispo> luke-jr: Fedora uses conservative power8
< sipa> luke-jr: how about the LE variant?
< luke-jr> sipa: -mcpu=970 does not work on LE at all
< luke-jr> note while technically PPC64 has always been bi-endian, the 970 CPU was firmware-tied to BE
< sipa> luke-jr: i see
< sipa> and the LE ones are built as power8
< sipa> luke-jr: i guess the most popular 970 hardware would be imac g5's?
< yanmaani> why does bitcoin only support certain arches?
< yanmaani> if you'd compile it for all arches and run the tests, wouldn't that catch undesirable unportable code?
< luke-jr> sipa: yes
< luke-jr> yanmaani: what?
< sipa> luke-jr: that sounds rather ancient :)
< luke-jr> sipa: indeed
< yanmaani> luke-jr: If Bitcoin Core is written in conforming C++, it should work on all arches, right?
< yanmaani> so isn't it good for code quality to run the tests on all arches, even the totally obscure ones?
< luke-jr> yanmaani: if possible
< yanmaani> Why would it be impossible?
< luke-jr> nobody willing to do it?
< yanmaani> if you're using qemu anyway, can't you just add all the arches to travis?
< luke-jr> shrug