IRC channel logs

2024-09-27.log

back to list of logs

<cpli>thank uu
<dsmith>rlb, wingo, What is the (potential) fix for 32bit 3.0.10 ?
<rlb>dsmith: not sure.
<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.
<daviid>wingo, dthompson, or any goops guru, any idea about this problem i am facing - https://paste.debian.net/1330530/
<rlb>wingo: i386 build after "git clean -fdx" (suggest no one run that without knowing what it does :) ) fails with number.test errors: https://paste.debian.net/hidden/c901da9c/
<rlb>It did *not* fail there for a build after just a pull --rebase.
<ArneBab>haugh: I do not remember it, but mu4e finds it ☺ https://srfi-email.schemers.org/srfi-234/msg/24436564/
<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>rlb: i can repro!
<wingo>yay
<rlb>wingo: oh, nice.
<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.).
<rlb>right
<wingo>but if you do the floor on the 80-bit number you get 90
<wingo>so the result is instead
<wingo>$1 = 90.0
<wingo>$2 = 1.4285714285714257
<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.
<wingo>i guess -msse2
<wingo>ok :)
<rlb>I'll also have to check what we/debian require wrt LCD cpu.
<rlb>there
<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..
<wingo>funny!
<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>and - https://www.debian.org/releases/testing/release-notes/issues.en.html#i386-is-i686 So if i686 requires sse2, then even -msse2 may be fine. Though I don't know that offhand.
<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>great
<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.
<rlb>fwiw
<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
<wingo>and passes tests, whee
<sneek>mwette: Greetings
<mwette>sneek: botsnack
<sneek>:)
<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.
<rlb>bbl