On Tue, Mar 18, 2025 at 01:51:49PM +0000, Scott Ashcroft wrote: > On Tue, 2025-03-18 at 01:32 +0100, Daniel Gröber wrote: > > We've seen FST problems due to i386 floating point weirdness before > > (rounding, 80bit>64bit conversion IIRC). Might just be something like that > > again. > > Looks like you are spot on. > The i386 and amd64 versions write identical FST files. > When the i386 version tries to read back the file it has just written > it fails trying to do an endian check on doubles. > > Commenting out the check at libs/fst/fstapi.cc:4727 makes the FST tests > pass. > Maybe we need to replace it with a test which says it is within a > delta.
Last time it just needed a strategically placed (double) cast. Idk why this would have started breaking again? > The same code is used in gtkwave and iverilog so it looks like nobody > cares about i386. > > > Could drop 32bit or just skip tests there. I may have a quick look tomorrow > > and drop if its too annoying. > > If we just skip the tests then the i386 version won't be able to use > FST files at all. > > Assuming we fix that up somehow then a bunch of other tests fail on all > 32-bit archs. > > simple/string_format > simple_abc9/string_format > > both make iverilog try to malloc huge amounts of memory. I can't tell > if the problem is on the yosys or iverilog side of things. > > The tests in cxxrtl fail too. No floating point so I guess just a size > of int/pointer mismatch somewhere. > > I suspect just dropping 32-bit support is going to be easiest way > forward as the upstreams of major bits of the FPGA workflow are broken. Ugh, yeah, screw this. Even many embedded things have 64bit support these days. I don't see the use-case for yosys on 32bit. nextpnr is still working on i386 at least, but oh well ;-) I filed a ftp-master RM (removal) request for the affected arches ($ reportbug ftp.debian.org). --Daniel
signature.asc
Description: PGP signature
