IRC channel logs
2024-09-27.log
back to list of logs
<dsmith>rlb, wingo, What is the (potential) fix for 32bit 3.0.10 ? <rlb>wingo: main works fine on amd64, but still crashes on debian unstable i386 in <rlb>ERROR: format.test: ~f fixed-point: ~2f - arguments: ((out-of-range "string-ref" "Argument 2 out of range: ~S" (18446744073709551615) (18446744073709551615))) <rlb>...as of aff9ac968840e9c86719fb613bd2ed3c39b9905c. I'm going to try a clean-tree build there too now. <rlb>It did *not* fail there for a build after just a pull --rebase. <ArneBab>haugh: arg, and then saw that you found it … <wingo>rlb: hoo, that is weird. that code involves no scheme (is all in c) <wingo>omg rlb this error is due to x87 fp <rlb>haha, you might not believe this, but I almost suggested that. <rlb>Then thought -- that can't be it, you're just having a knee-jerk reaction :) <rlb>(And in truth, that too -- i.e. I didn't have any good foundation for the guess.) <wingo>well. so the error comes in computing (floor/ 130.0 10/7) <wingo>the exact result is 91. it is computing 90, instead. <wingo>because when the x87 divides, it gets 90.9999999999999979808 <wingo>which, at 64 bits, is just 91 <rlb>I don't actually know what we/scheme require/promise there wrt behavior with extra precision "sometimes" (if I understand some of what x87 implies, depending of course on the compiler options, optimizations, etc.). <wingo>but if you do the floor on the 80-bit number you get 90 <wingo>and the thing is, $2 is the same as 10/7 in 64-bits <wingo>so the test says, ah-hah, the remainder should be less than the divisor <wingo>i don't think this code has changed since the last release <wingo>but different inlining heuristics can lead to more or less x87 ops <rlb>Yeah, I'd have naively guessed "compiler". <rlb>I'm using whatever's current debian unstable fwiw, in that vm. <wingo>i am testing with guix, whatever it uses <wingo>rlb: wdyt about adding -msse -mfpmath=sse to the i386 build <rlb>Umm, may have to get back to you after catching up (doing some homework) :) <rlb>Might be a day or so -- probably should wander off soon for today, but I'll get back to you. <rlb>I'll also have to check what we/debian require wrt LCD cpu. <rlb>We can also disable x87 iirc, but not sure how bad that might be, and/or how commonly done. <rlb>wingo: I knew this rang a vague bell, and sure enough, I patched out those test errors in debian years ago: "Disable unresolved "mixed type" numbers.test division tests on i686. <rlb> Add 0006-numbers.test-disable-unresolved-mixed-type-division-.patch to incorporate the changes. <rlb>...that paste didn't go well.. <rlb>did you also see -fexcess-precision=standard? <rlb>(-fno-fast-math had come vaguely to mind, and then I noticed it includes that) <rlb>Or I think it may -- -ffast-math definitely does the opposite :) <wingo>we should certainly not do -ffast-math!! <rlb>no, I meant -fno-fast-math :) <rlb>and wasn't suggesting we use it, just that I remembered it wrt x87, which led me to excess-precision <rlb>I saw one place suggesting both -msse2 *and* -mfpmath=sse, but haven't investigated. That place also said that even with those, you'll can still get 80-bits via some trancendentals that aren't provided by sse. <rlb>No idea if all that's right yet. <rlb>ACTION wanders off soon for "hours" <wingo>never using 80-bit would be fine, but i think we just need "good enough" <rlb>wingo: oh, and to clarify, in case you hadn't assumed, this is of course no longer a blocker as far as debian's concerned. I only hit it because I was building from a clone, not the package. <wingo>i will see about making a release soon <rlb>(We've been ignoring that test for a while.) <rlb>(for better or worse) <rlb>I'll look at a few patches I had pending -- one for a guile-procedures.txt race with parallel builds that might or might not still be relevant (you may have done something there since, too). <rlb>I should be able to do that tomorrow or Sat. <wingo>-march=i686 doesn't enable sse, it seems <rlb>(Offhand, docs *sound* like -fexcess-precision=standard might be what we want, if what we want is IEEE/c99-ish.) <rlb>(from a cursory look) <wingo>but '-msse2 -mfpmath=sse' does get the expected results <rlb>wingo: -fexcess-precision=standard also fixes the number.test failures here. If sufficient, wondered if that might be more portable, *if* our tower actually does expect c99-ish semantics -- and then perhaps sse support is somewhat orthogonal? <rlb>(looks like clang supports it too fwiw) <wingo>rlb: honestly i would prefer an option that only applies to i686 <wingo>i.e. add flags when on i686. no preference whether it's -mfpmath or -fexcess-precision <rlb>wingo: oh, I thought there was a chance we might want "standard" floats everywhere, i.e. if some other arch ends up with a similar effect. <rlb>No strong opinion, though. <rlb>(don't even know exactly what our mathematical model expects there offhand) <rlb>wingo: in any case, if you think one of those options is sufficient, i.e. shouldn't break anything, then I can at least change the debs for now and re-enable that test. i'd also be happy to attempt a patch for main, but only if you aren't planning to handle it.