FFY00_ has quit [Remote host closed the connection]
FFY00_ has joined #yosys
kraiskil has joined #yosys
s_frit has quit [Remote host closed the connection]
s_frit has joined #yosys
kraiskil has quit [Ping timeout: 260 seconds]
emeb_mac has quit [Quit: Leaving.]
s_frit has quit [Remote host closed the connection]
s_frit has joined #yosys
s_frit has quit [Remote host closed the connection]
s_frit has joined #yosys
s_frit has quit [Remote host closed the connection]
s_frit has joined #yosys
shivampotdar has joined #yosys
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
wiizzard has quit [Quit: Idle for 30+ days]
vidbina_ has joined #yosys
jakobwenzel has joined #yosys
vidbina_ has quit [Ping timeout: 256 seconds]
FFY00_ has quit [Remote host closed the connection]
FFY00_ has joined #yosys
<gatecat>
somlo: done
craigo has quit [Ping timeout: 245 seconds]
craigo has joined #yosys
FFY00_ has quit [Remote host closed the connection]
FFY00_ has joined #yosys
jakobwenzel has quit [Ping timeout: 265 seconds]
FFY00_ has quit [Read error: Connection reset by peer]
FFY00_ has joined #yosys
kraiskil has joined #yosys
kraiskil has quit [Ping timeout: 260 seconds]
jakobwenzel has joined #yosys
vidbina_ has joined #yosys
jakobwenzel has quit [Ping timeout: 246 seconds]
<somlo>
gatecat: thanks!
<somlo>
I requested a Fedora RPM build of yosys (at commit 9cdc6b5, as of yesterday). That involves building on a variety of architectures (686, x86_64, arm, ppc, s390x).
<somlo>
it builds everywhere, and passes tests on all but s390x, where tests/techmap/shiftx2mux.ys fails with
<somlo>
"ERROR: Called with -verify and proof did fail!"
<somlo>
currently I'm working on peeling off all the fedora-specific layers to try and create the most straightforward reproducer possible for a bug report (probably no way around involving qemu-s390x-static :)
<somlo>
in the mean time, any insight into the shiftx2mux.ys test much appreciated -- I'm not ready (yet) to simply turn off the "%check" (`make test`) portion of the build on s390x to paper over the issue -- on the off chance this failure might be highlighting an actual problem...
lethalbit has quit [Read error: Connection reset by peer]
lethalbit has joined #yosys
<gatecat>
Thanks for looking into this - I'll raise this on the Yosys HQ slack too
<mwk>
... oh yay
<mwk>
.... I wonder what happened to that cursed s390x VM I had laying around
<somlo>
mwk: after turning yosys #9cdc6b5 into a .src.rpm, I can reproduce it with `mock -r fedora-rawhide-s390x yosys*.src.rpm` -- which involves containers and emulation via qemu-s390x-static, i.e. "usermode" emulation)
<mwk>
any chance of getting some reproducer I could run with just plain qemu?
<mwk>
but anyway
<somlo>
that's what I'm trying to do, "peel off" all the fedora-specific crap before filing an issue on github
<somlo>
wouldn't want to inflict the RPM crap on anyone who isn't a Fedora nut :D
<mwk>
as far as I can see, that sat -verify call basically verifies the validity of a techmap + abc/abc9 on a design
<mwk>
the actual shiftx2mux part shouldn't be relevant to this failure
<mwk>
so the question is
<somlo>
abc bug?
<mwk>
is one of these passes somehow broken on s390x, or is the sat itself broken
<mwk>
not impossible
<mwk>
but anyway
<mwk>
I'd suggest modifying the test to dump rtlil at three points in the script
<mwk>
and uploading the resulting files somewhere so we can compare with known-good execution
<mwk>
please add: `write_rtlil gold.il` right before `design -save gold`
<mwk>
`write_rtlil gate1.il` right after first `select -assert-count 16 t:$lut`
<mwk>
`write_rtlil gate2.il` right after second `select -assert-count 16 t:$lut`
<mwk>
and upload the three il files that appear (or two if it crashes earlier)
<mwk>
also could you upload the full execution log of that test? I'm not even sure *which* sat call crashes
<somlo>
mwk: https://pastebin.com/kYmRATps -- I'll get back to you here once I collect the output. And yeah, I'll dig around for the execution log as well. Thanks!
<somlo>
mwk: happy to open an issue on github if you prefer, just LMK
<mwk>
well, sat doesn't pass here either on those
<mwk>
so... abc or techmap bug
<mwk>
somlo: is s390x the only big endian architecture you tested?
<mwk>
actually hmmmmm
<somlo>
mwk: the full list is armv7hl, i686, x86_64, aarch64, ppc64le, s390x
<mwk>
and that means a no
<mwk>
I just pulled up a ppc64 machine, let's try it
<mwk>
er, I mean, that means a yes; s390x is the only BE one on that list
<mwk>
yep
<somlo>
yeah, ppc64le sounds like the "le" bit is for little
<mwk>
the test fails
<mwk>
okay, this means I have a repro machine
<somlo>
oh, so it's an endianness thing
<mwk>
yes
<mwk>
not a good sign, is it
<somlo>
thank goodness I don't have to peel off the fedora container layers, if you can reproduce on your end :)
<somlo>
but yeah, sorry about the less than good news
<mwk>
and I just confirmed that it is, indeed, abc and not techmap
<mwk>
gods, I do *not* want to dig into abc sources to find a fucking endianness bug
<somlo>
I have mixed feelings of sadness and relief at clearly not being qualified to tackle this myself :D
<somlo>
at least not in any useful time frame...
<mwk>
and it's a dangerous one, too
<mwk>
as in, it silently mangles synthesized logic
<mwk>
given this issue, yosys should be considered unusable on big endian machines
<mwk>
at least for synthesis flows
<somlo>
ouch...
<somlo>
but at least we know, which is arguably better than the alternative
<mwk>
yes
<mwk>
please file a bug, this needs to be fixed
<somlo>
will do
<cr1901_modern>
oh shit ._.
<somlo>
mwk: issue #2645
kraiskil has quit [Ping timeout: 256 seconds]
emeb_mac has joined #yosys
jakobwenzel has joined #yosys
jakobwenzel has quit [Ping timeout: 265 seconds]
vidbina_ has quit [Ping timeout: 260 seconds]
jakobwenzel has joined #yosys
<mwk>
somlo: the culprit seems to be the mfs2 pass in abc; I can make the testsuite pass by removing mfs2 from the default script in passes/techmap/abc.cc
jakobwenzel has quit [Quit: jakobwenzel]
<jix>
mwk: I found the bug (see slack)
<mwk>
oh ffs
<mwk>
somlo: given the underlying mess, you may want to just fail the build on big-endian systems
<mwk>
this is just a case of someone baking a little-endian assumption deep into the code, fixing this is going to involve a *lot* of work
<somlo>
mwk: thanks, I'll ask in #fedora-devel how to go about "unsupporting" a package on one of their "supported" architectures (the irony is that I couldn't care less about s390x for myself or anyone I know :)
<somlo>
mwk: the baked-in assumption, is it in upstream abc? If so, any chance one of you kind folks can open a bug about it in upstream abc that I can reference to support my case with #fedora-devel ?
<mwk>
yes, upstream abc
<sorear>
are you asking a political question or a question about rpmbuild?
<sorear>
on second thought it's been several years since I did this and I'm not sure I could explain how
danvet has quit [Ping timeout: 272 seconds]
<sorear>
but there's a way to stick architecture allowlists/denylists in spec files and a bunch have them
<somlo>
sorear: it's technically possible to specify "this package should not be built on this arch" (and quite a simple one-liner in the rpm spec file)
<sorear>
yeah but saying "it's easy" without details is not useful, so I'm not doing that
<somlo>
but (without having crossed all my t's and dotted all my i's) I also assume that if we had yosys and abc packaged for all arches before, stopping that on arch "foo" would be easier if I could point at some good reason :)
<somlo>
besides, having the breakage documented and on record is a good thing on general principle, nevermind "packaging politics"...
<somlo>
I'd do it, but (as I might have mentioned earlier) this is WAAAAY deeper and darker voodoo than I am currently qualified to handle -- all I did was step on the landmine, and I don't have the vocabulary to describe it in technical detail :)