ChanServ changed the topic of #yosys to: Yosys Open SYnthesis Suite: https://github.com/YosysHQ/yosys/ | Channel logs: https://libera.irclog.whitequark.org/yosys/
tpb has quit [Remote host closed the connection]
tpb has joined #yosys
GenTooMan has quit [Ping timeout: 245 seconds]
GenTooMan has joined #yosys
Tokamak_ has joined #yosys
Tokamak_ has quit [Quit: Tokamak_]
hrberg has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
hrberg has joined #yosys
hrberg has quit [Client Quit]
hrberg has joined #yosys
ec has quit [Read error: Connection reset by peer]
ec has joined #yosys
citypw has joined #yosys
citypw has quit [Remote host closed the connection]
bjork1intosh has joined #yosys
bjorkint0sh has quit [Ping timeout: 260 seconds]
bjork1intosh has quit [Ping timeout: 246 seconds]
philtom has quit [Ping timeout: 250 seconds]
philtom has joined #yosys
philtom is now known as philtor
<somlo> I'm packaging yosys for fedora (where bundling is strongly discouraged).
<somlo> abc built from upstream commit 66a5fe7 (in f38), but one of the aiger checks
<somlo> I can build the latest yosys (commit b04d0e0) without any problems against
<somlo> make[1]: Leaving directory '/builddir/build/BUILD/yosys-b04d0e09e83102e14a53bb8b8dcc8c35f63b2fbe/tests/opt'
<somlo> is failing when I use commit e61194b (in rawhide/f39):
<somlo> cd tests/aiger && bash run-test.sh "-A /usr/bin/abc"
<somlo> Checking and_.aag.
<somlo> Checking buffer.aag.
<somlo> ...
<somlo> Checking false.aag.
<somlo> run-test.sh: line 19: 31937 Segmentation fault (core dumped) $abcprog -q "read -c ${aag%.*}.aig; write ${aag%.*}_ref.v"
<somlo> I'm guessing the problem is caused by one of the 28 commits by which upstream
<somlo> is ahead of the "vendored" yosyshq/abc (or rather the 23 commit subset thereof
<somlo> ending with e61194b).
<somlo> Before I go the "maximum effort" route and blindly try them all, does anything
<somlo> look like a good candidate to the eye of a trained expert? :)
FL4SHK has quit [Ping timeout: 240 seconds]
<somlo> guess I'll bisect upstream commits [039f05c ... e61194b] (everything newer than the vendored yosyshq/abc that's in f39/rawhide), and maybe find the "landmine" :)
bjorkintosh has joined #yosys
bjorkintosh has joined #yosys
bjorkintosh has quit [Changing host]
<tnt> pretty sure that not using the specific abc version specified in yosys is a NO NO.
<somlo> tnt: it's been working great for several years, so there's that :) Besides, I feel this is a landmine worth defusing for if/when the "vendored" abc is updated/rebased to upstream
<somlo> tnt: for context, yosyshq/abc is rather minimally divergent from (currently 50-something commits ahead, 28 commits behind) upstream, which to mee is a good sign that important changes are still being pushed
<somlo> the alternative (completely fork it and stop tracking upstream) would be what would prompt me to give up and go with the "vendored" version, but that doesn't seem to be what's happening
<somlo> but in that case, I'd expect a replacement or rewrite, rather than a mere (bit-rotting) fork :)
<tnt> Well yosys updates their vendored in regularely ... but they also know what they're doing and what those patches they carry over are for and why they're there.
nonchip has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nonchip has joined #yosys
<whitequark> somlo: packagers never seem to understand "this specific configuration is supported and others are not"...
<whitequark> like if you're willing to become an expert in abc's quirks, godspeed, but if you aren't, then why are you expecting others to do the work you invented out of thin air for you?
<somlo> whitequark: I may be mistaken, but it *seems* yosyshq/abci *is* after all tracking upstream abc in some sort of fashion. In that case, I found a potential issue y'all might be running into when rebasing at some future point (you're welcome, btw). I figured it's worth a quick question, but I'm happy to bisect the upstream commits that are *not* in yosyshq/abc and find which one is going to cause the problem :)
<whitequark> it's more about getting bug reports and then discovering that the bug is caused by using an unsupported version of abc
<whitequark> this is one of the reasons why Glasgow defaults to pulling Yosys+abc+nextpnr from https://yowasp.org instead of using the system one...
<tpb> Title: YoWASP | Unofficial WebAssembly-based packages for Yosys, nextpnr, and more (at yowasp.org)
<somlo> I'm actually hoping some brave soul will *properly* fork ABC and allow everyone to just switch to the *one true dependency* (instead of this balkanized proliferation of half-assed forks we have now, apparently ;P )