IRC channel logs


back to list of logs

***wxie1 is now known as wxie
***jonsger1 is now known as jonsger
***wxie1 is now known as wxie
***jonsger1 is now known as jonsger
***sneek_ is now known as sneek
<roelj>I see there's a new ‘pipeline’ function :D. Is it equally fast/efficient as using pipes in bash?
<roelj>(I want to pass 100+ GB through a pipe..)
<wingo>hi :)
<wingo>civodul: good job on 3.0.3 release :)
<wingo>civodul: excepting one thing tho. pretty sure chris vine is right, that the change to the libtool version was incorrect
<wingo>we should clarify that --disable-deprecated builds do not have stable ABI, and that symbols of such binaries may disappear at any thing
<wingo>will send that to the list
<civodul>hi wingo!
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, efraim says: I'll test the JamVM patches on aarch64 but I don't want to be responsible for breaking other architectures :)
<civodul>like i said, i was hesitant
<civodul>but thought we'd rather be safe than sorry
<civodul>but yeah, dunno, we don't have a documented procedure for that
<wingo>civodul: pretty sure all through 2.2.x we deprecated things
<wingo>keeping the soname
<wingo>between keeping those changes and changing the soname, i would have reverted the bitvector changes on 3.0, fwiw
<wingo>i.e. i only made them thinking that it would preserve ABI compatibility
<civodul>wingo: yeah
<civodul>i understand
<civodul>i don't see changing the SONAME as that big a deal (to me it's less serious than not changing it when it should have been changed)
<civodul>but i agree it creates annoyances
<civodul>sorry about that
<civodul>Debian for instance will have to rebuild all the dependents of guile-3.0
<civodul>from then on, i'm find with the policy you suggest: ignoring --disable-deprecated ABI stability
<civodul>what course of action would you suggest now?
<wingo>i don't know. i would suggest reverting, tbh
<wingo>i mean releasing a quick 3.0.4 with CURRENT reset to what it was, and adapting the other two versions appropriately (I always have to look at the manual to see how to do it)
<wingo>like it's not simply that debian would have to rebuild guile-3.0; it means they would have to have libguile3.0-42 vs libguile3.0-43
<wingo>which is not what we intended i think
<civodul>"the other two versions"?
<civodul>ah you mean the libtool numbers
<wingo>AGE and REVISION or whatever
<civodul>should i do that?
<wingo>if you have the cycles, yeah
<civodul>well, i don't, but if it has to be done...
<wingo>well let's try between the two of us, in the meantime would you mind following up to the list with a note saying that we're going to release 3.0.4?
<wingo>like we should avoid a cascade of problems with distributions
<wingo>so maybe sending a note will give us the time to take care of it
<civodul>just emailed the list
<civodul>probably best to avoid having distros get into troubles
<wingo>not all distros are as advanced as guix ;)
<civodul>wingo: after the revert, this gives something like this:
<civodul>actually there's a new scm_bitvector_position
<civodul>so that gives this:
*wingo looks
<wingo>yes i think that's right
<wingo>the second patch you post
<wingo>because we are in case (2)
<wingo>friggin abi
<wingo>i guess we should add some comments there. basically in a stable series we either increment both CURRENT and AGE -- that being the default option -- but if we know that nothing was added ABI-wise, we can just increment REVISION
<civodul>i end up rereading the Libtool manual every time and going through git log
<civodul>perhaps we should just use libabigail
<wingo>thanks for working through this with me and apologies again for the bother
<civodul>well, in hindsight, it was undoubtedly a mistake
<wingo>lots of guile is a mistake in hindsight ;-))
<civodul>wingo: how about this for NEWS?
<wingo>civodul: lgtm
<dsmith-work>Hey Hi Howdy, Guilers
***wxie1 is now known as wxie
<wingo>heya dsmith-work
<dsmith-work>wingo: Greetings.
<dsmith-work>wingo: Did you happen to see the clang/arm breakage in the jit?
<wingo>dsmith-work: you referring to ?
<wingo>(also, are you using clang for your guile builds?)
<dsmith-work>Yes, that case. Not using clang. That's RhodiumToad using fbsd on rpi.
*RhodiumToad raises hand
<wingo>that's a very interesting bug
<wingo>i wonder why it doesn't cause more problems
<wingo>do other abis not require writing the full word?
<wingo>i would guess not but apparently all this is paged out of my brain :P
<dsmith-work>wingo: x86 doesn't require zero padding I think. The abi doc I was looking didn't say for chars/shorts, but *did* mention bools.
<dsmith-work>Bit 0 is 0or1, bits 1-7 must be 0, other bytes are don't-care.
<wingo>yeah that is what i found too (of course looked at the abi doc but i wanted interpretation about something it was silent about)
<wingo>!topic/x86-64-abi/E8O33onbnGQ <- related
<RhodiumToad>wingo: gcc doesn't seem to assume that the caller of a function is following the ABI strictly. this is probably not really intentional, just an artifact of how it deals with data
<RhodiumToad>whereas clang for whatever reason assumes that the ABI is followed
<RhodiumToad>x86 requires bools are padded to bytes because it's easier and faster to check a byte for zero than a bit
<RhodiumToad>but x86 doesn't otherwise require padding because, at least historically, forcing sign-extension or zero-extension slowed things down
<RhodiumToad>whereas arm (at least in 32-bit, I haven't done anything with aarch64) tends to favour word-size accesses everywhere
<wingo>i guess lightening should (a) assume that its registers are properly extended, e.g. that loading a u8 zero-fills any high bits, and (b) add "_abi" variants for the various store APIs, which backends can implement
<wingo>generally speaking we will make them equivalent to word-size stores for values <= word-size
<wingo>sound about right?
<wingo>or maybe we can simplify and just use `jit_str` to store the values (i.e. the word-size variant)
<RhodiumToad>_assuming_ that loading a value fills the high bits is a bad idea
<wingo>from looking at the code in firefox, that is what it seems to do
<wingo>RhodiumToad: pretty sure it is guaranteed by construction in the jit
<wingo>could be wrong tho!
<RhodiumToad>it is for arm, but what about other architectures?
<wingo>from what i can tell it's general at least across x86/x64/arm/aarch64/mips32/mips64
<wingo>could be another platform is different but it sounds unlikely and we can cross that bridge later i guess
<wingo>needs thinking about tho
<wingo>alternately we could emit extz / exts calls for "small" data types
<wingo>when passing them as args
<wingo>maybe that is safest
<wingo>could break some dependency chains too...
<RhodiumToad>hm, yeah, I see that x86 is using movzx / movsx to generate byte loads
<civodul>wingo: 3.0.4 uploaded!
<wingo>*clap clap clap clap*
<wingo>RhodiumToad: yeah consider, you do ldr_c (R0, addr); jnz(R0, L0). there i think the lightening API really means that loading an int8_t does sign extension
<wingo>otherwise the result of the comparison would be undefined, if the high bits weren't defined
<RhodiumToad>well I'm fairly new to lightening, hadn't looked at it before tackling these bugs
<wingo>lol, i used to know lightening, but apparently i forgot everything about it; high five to the lightening newbies club
<RhodiumToad>so I think the approach that feels best to me is to have an _abi variant for stores, meaning "store a value of this size in the way that the platform ABI expects"
<wingo>"good" news would be that the fix to this bug is straightforward: just use jit_str instead of jit_str_c when passing stack args. similarly for _s and _i
<wingo>assuming that is compatible with all platform ABIs, which i think it is for the ones that lightening supports
<RhodiumToad>note that I haven't checked on what aarch64 does.
<RhodiumToad>(I don't have any aarch64 hardware to check)
<wingo>from firefox things i know that writing u8 args as word-size values isn't incompatible; whether it's required or not, i don't know.
<wingo>(i wonder why armv7 is loading the whole word from the stack instead of just the byte; easier to encode?)
<RhodiumToad>clang on aarch64 is _not_ loading or testing a whole word, just a byte
<RhodiumToad>at least from doing examples on godbolt
<dsmith-work>I've got an aarch64 board.
<dsmith-work>Need to fire that thing up too.
<wingo>all hail godbolt
<dsmith-work>YEah, that's really useful.
*wingo gtg, biab
*RhodiumToad finds the aarch64 abi doc
<RhodiumToad>ok. so aarch64 explicitly does _not_ do the same padding that 32-bit arm requires
<dsmith-work>Bah. Board has power supply problems.
<RhodiumToad>an integer value smaller than 8 bytes is passed in the low order N bits of an 8-byte slot (register or memory), but the remaining bits are unspecified
***ChanServ sets mode: +o civodul
***civodul changes topic to 'Welcome to #guile. See for more information. Guile 3.0.4 is out! <>. This channel is logged, see <>. Bug database at <>.'
<dsmith-work>RhodiumToad: Souund like the x86 stuff.
<dsmith-work>civodul: need to tag v3.0.4 ?
<zig>Thanks whoever fixed the bug in guile 3.0.3 my project works again :)
<civodul>dsmith-work: tag pushed, thanks for the reminder!
*dsmith-work bows with a flourish
***sneek_ is now known as sneek
<dsmith-work>sneek: seen rlb?
<sneek>rlb was in #guile 6 days ago, saying: Though I still need to think through whether or not that really makes sense here....
<sneek> 17:42:55 up 2 days, 5:35, 0 users, load average: 0.19, 0.06, 0.06