IRC channel logs
2025-09-03.log
back to list of logs
<rlb>wingo: if you think that's appropriate for main too, and want to add it, or want me to try to add it, great. <dsmith>rlb, Oh "thanks". Now I've got that Devo tune in my head... <ArneBab>rlb: I’d say it’s an override. Setting ./configure CFLAGS="-g -O2 -march=native -Werror=array-bounds -flto -ffat-lto-objects" gets me the correct results (but only builds with main; seems like -ffat-lto-objects requires main) <ArneBab>ACTION is currently running one more test. <rlb>i.e. roughly from pointer to function -> void* <omentic>hey yall. i'm running into some strange errors with define-public. do i need to add an extra import to be able to use it with guild? <omentic>i thought i wouldn't, as i don't run into errors using it in the repl, but i'm getting an unbound variable error on define-public. i haven't been able to find the module i'd import, though. <ArneBab>results from r7rs on a few releases (slowdown compared to fastest, two results each): v3.0.8 1.04 1.06 , *9 1.05 1.05, *10 1.09 1.11, main 1.09 1.09 <rlb>ArneBab: thanks for testing <ArneBab>I did not yet try to find the commit that causes the slowdown. <ArneBab>I bisected the history and the cause for the slowdown seems to be 85f85a0fc03476303e8d8470d86c541d9f49b500: Tree-IL-to-CPS lowers to high-level object reprs: vectors <ArneBab>that caused a 2.5x slowdown for the array1 benchmark. <ArneBab>my test: (make || (make clean; autoreconf -i ; ./configure ; make)) && (cd ~/eigenes/Programme/r7rs-benchmarks && GUILE=~/eigenes/Programme/guile/meta/guile ./bench guile array1; echo ; echo 3.0.9 is Elapsed time: 1.162592941) <wingo>ArneBab: interesting! tx for the triage / bisection <wingo>yes i would like to look into that <kkremitzki>That's "Guile fails to build with GCC 15", wasn't sure if a bot would come through with the title <rlb>kkremitzki: right - not forgotten, but not fixed in main yet either. I was looking at that myself a bit yesterday. <rlb>If anyone else has time, and enough C knowledge, could you take a look at this proposed patch to fix gcc 15 compatibility -- I'd like a second opinion. I'm also looking at it, and testing it, wondering if we might be able to include it in 3.0.11. <rlb>(same one from yesterday) <rlb>I did double-check with someone else who's very knowledgeable on the C front about the API fn* to void* change, and they also thought it was probably fine if we end up needing it. <dsmith>rlb, Looks ok to me. A shame function pointers must be void *. The only issue I can image is if a code address and a data address are not the same size? <dsmith>ACTION shudders at the memory of near/far pointers on DOS. <rlb>The other person also mentioned powerpc (apparently may have "descriptors") and wondered about CFI (new Control Flow Integrity stuff), but didn't think either would be an issue in practice for now. <rlb>ACTION has read a bit about CFI over the past while via lwn... <old>if you have questions regarding CFI, I know lots of stuff on that <old>I assume you are talking about Intel CET with shadow stack and indirect branches tracking <rlb>I'd guess -- though I think it's probably not a concern here in practice, but if you look at the patch change and think otherwise, by all means, shout. <old>rlb: which patchset? <old>okay I'll have a look <rlb>mainly the scm.h change, but of course anything else -- the question is just "what's good enough for 3.0.11" because wingo already has a fancier fix in his wip-whippet work using Generic(). <rlb>dsmith: nice - and also confusing. It's not clear to me from that either that it's *formally* safe to round trip *functions* through void* from that and the linked doc(s). i.e. part of the spec distinguishes object pointers from function pointers, but then that "J" section at least defines void -> fn -> call. <rlb>That also mentions the "descriptors" case. <rlb>the n2230 doc summary also says that posix requires it anyway? <rlb>if so, the maybe we don't care, because "it's going to be fine for us". <rlb>i.e. from the N2230 doc: "To allow runtime symbol binding, the POSIX standard, for example, requires that function pointers be convertible to void* and vice versa." <rlb>(...and dlsym, etc.) <old>I've neever seen any problem from casting any function on any sane archiecture to void * then back to its type later and call it <old>DLL and shared lib basically work on that assumption .. so <rlb>That was my gut feeling, but I get very cautious when the guile ABI is involved :) <old>I don't see any concern for CFI here. I guess the JIT emitter ought to emit endbr64 at its entry tho in the future for supporting that <rlb>ACTION is also testing it on ppc64el atm... <old>if you have some yocto around why not <rlb>If the ppc64el tests succeed too (already tested amd64), I'll review the patch a bit more carefully, and then may consider adding it to main. <rlb>I may also see if I can come up with an initial regression test for the concurrent initialization segfault. <old>Do you have some DEC Alpha silicone to try on <old>that's probably the weirdest arch that could have something insane with function pointers <rlb>But we could find out if I uploaded main to experimental. <old>I mean, nobody is using alpha <old>Linux has dropped support for it <old>it's just a weird arch that does crazy stuff <rlb>dsmith: did you see any reason we couldn't just "static SCM default_dynamic_state = SCM_BOOL_F;" in threads.c instead of the init in scm_init_threads? If not, that seems better (fewer states to worry about, and an easier guard in guilify_self_2. <rlb>(passes the tests, and works with the bug example at least) <rlb>configure.ac says "PKG_CHECK_MODULES([BDW_GC], [$bdw_gc >= 7.2]) <rlb>I'm wondering if that means we can drop the guard in test-pthread-create-secondary.c. <rlb>i.e. if that bug was fixed in 7.2. <dsmith>rlb, Actually, I was wondering something along those lines. <dsmith>rlb, Something I learned a long time ago: **NEVER** let a SCM be NULL <rlb>I've changed my patch to do that, and it "seems fine". I think we should consider it for 3.0.11 -- working on a standalone concurrent init test now. <rlb>(hence the question about the guard when looking at existing pthread-related tests) <rlb>also wonder if other platforms might be fine now too. <rlb>?been a long time"... <rlb>I might make the concurrency test less guarded and I can test on freebsd... <rlb>I'm guessing the same concern might apply to the concurrent init test. <rlb>But for .11 we might ought to keep it restricted to __linux__ -- should still shake out "most things". <dsmith>I just the other day spun up a 14.3 fbsd vm. <rlb>yeah, I typically keep one handy for bup-related issues. <dsmith>Heh. ./autogen.sh on fbsd. m4 doesn't know --version <dsmith>rlb, fbsd needs boehm-gc-threaded, right? <dsmith>Yeah, got linker errors. Needed to pass the .pc name of the threaded libgc <rlb>dsmith: no idea - don't know if I've ever messed with guile on fbsd. <ttz>When evaluating ,optimize (if (pair? p) (let ((a (f))) (if (pair? p) #t #f)) #f), I get (and (pair? p) (begin (f) (and (pair? p) #t))). I do not understand why the optimizer cannot reduce it to (and (pair? p) (begin (f) #t)) <identity>ttz: i would guess it is for the same reason it can not reduce (and (pair? p) (pair? p) #t) to (and (pair? p) #t): not smart enough <rlb>possible fix for the concurrent init issue ^ <ttz>identity: could some side-effect-freeness guarantee be missing? <dsmith>rlb, Guile git head on fbsd 14.3 release. test-system-cmds fails with a segfault. Have not tried your patch yet. (or the func() patch) <dsmith>I'm very curious, so I'll dig into it later this evening. <rlb>dsmith: does fbsd have a guile "package" of its own? <rlb>Be nice to eventually have ci for some notable debian/*bsd/etc. hosts. -- would have a good selection on sourcehut, and I believe there may be a codeberg bridge, but I assume we'd also need a ~$10/mo account somehow, assuming that were even considered appropriate. <rlb>...on the fully proprietary side, cirrus-ci has a good selection, free to free software, but I suspect it might not have any codeberg integration.