IRC channel logs


back to list of logs

<chrislck>mauritslamers: your function is fine. you can used named let for the state variables.
<rekado>gah, the rebase is really tricky
<rekado>Emacs 25 changed the way symbols are represented internally
***wxie1 is now known as wxie
***wxie1 is now known as wxie
<terpri_>rekado, how so (roughly)?
*terpri_ way behind on guile-emacs rebasing
***catonano_ is now known as catonano
***wxie1 is now known as wxie
***terpri__ is now known as terpri
<daviid>I pushed an important patch, to the G-Golf repo, devel branch: "Methods - Both long and short name generic functions" // this is an important milestone, for G-Golf, because till now, GObject methods were actually imported as procedures. They are now imported as goops methods. In addition, G-Golf also provides short name generic functions and method, 'just' like guile-gnome.
<daviid>str1ngs: ^^
<daviid>sneek: later tell tohoyn I pushed an important patch, to the G-Golf repo, devel branch: "Methods - Both long and short name generic functions" - please pull, make ... and see if everything is ok
<sneek>Will do.
<mwette>sneek: botsnack
<daviid>here is an updated <radio-button> example - - note the method short-name calls, destroy, join-group, set-active, add, pack-start and show-all
<conjunctive>Hi, I was wondering, how would you limit read-line to 512 characters in the context of the Fibers ping-server example?
<conjunctive>(for reference:
<leoprikler>daviid so I can do stuff like (destroy window) now just like in Guile-GI?
<leoprikler>Oh, I can, nice
<RhodiumToad>gmake[2]: *** [Makefile:2279: ice-9/iconv.go] Segmentation fault (core dumped)
<RhodiumToad>that's with threading disabled
<RhodiumToad>and it's a mov.w r12, #0 / ldrt r5, [r12] again
<RhodiumToad>grumble. and it doesn't reproduce
<RhodiumToad>this is with alsr on, so it may of course only happen with particular choices of memory addresses
<RhodiumToad>the last mov/ldrt error was with alsr off but threading on
<RhodiumToad>sod this, time to add an assert
<civodul>bytevector-u32-native-set! is mis-cross-compiled on master and not in 3.0.2
<civodul>generated CPS is the same as if the "target" fluid was ignored
<civodul>but i can't find where that expansion happens
<RhodiumToad>random guess, is this related to the change on Jun 1 that makes -O1 also do resolve-primitives?
<civodul>no, it's with -O2/-Ocps
<civodul>i didn't check -O1 actually
<civodul>the starting point of all this is that .go files under prebuilt/ for 32-bit platforms are miscompiled
<RhodiumToad>miscompiled only for endian-mismatched platforms or for all? because presumably an issue with bytevector-u32-native-set! would only be a problem in the event of endian mismatch
<civodul>RhodiumToad: AFAICS it's really just the word size that's problematic
<civodul>i need to investigate some more
<apteryx>what's happen when a guard close is missing an "else" for unknown condition types? The doc suggests it get rethrown but I'm not sure.
<apteryx>what happens*
<apteryx>nevermind, it seems to be related to the kind of exception that `canonicalize-path' throws
<apteryx>consider this: (guard (c ((message-condition? c) (format #t "error: ~a: ~a~%" "fixed-arg" (condition-message c)))) (canonicalize-path "/doesntexist")) --> error: fixed-arg: ~A: ~S
<apteryx>why doesn't the formatted string get produced right?
<dsmith-work>Happy Friday, Guilers!!
<guix-vits>dsmith-work: Thanks. Is sneek doesn't accept "later tell" from inside of '/query' any more?
<civodul>Happy Friday!
<civodul>dsmith-work: how's your debugging journey going?
<civodul>i just fixed that cross-compiled .go bug
<civodul>i'm testing it, but if everything goes well, all the lights are green for me
<dsmith-work>No success yet
<dsmith-work>Address randomization matters!
<dsmith-work>Turning that off makes the segfaults consistent.
<dsmith-work>single threaded seems to make it happen less often, but does not eliminate.
<dsmith-work>I tried to do a bisect on make check. GUILE_JIT_STOP_AFTER=1384 fails. 1383 works
<civodul>yeah, turning ASLR off is a good way to make bugs reproducible
<civodul>meanwhile i'll test on the machines i have access to
<civodul>is it OK if we release 3.0.3 ASAP and leave the bug fix you're working on for 3.0.4?
<dsmith-work>I think so.
<dsmith-work>Can aways just disable the jit.
<dsmith-work>That's still happeing for guix, right?
<civodul>no, we no longer disable JIT on ARM
<civodul>except for a statically-linked Guile variant
<civodul>so perhaps it's just that the issue had become rare enough
<dsmith-work>With the jit threshold at default, it happens rarely. But it can.
<civodul>yeah maybe we were just lucky then
<civodul>BTW, IIUC, the description at is not up-to-date, is it?
<dsmith-work>threshold at 0 pushes it harder
<civodul>if you have more details to describe how to reproduce it, what backtrace you get, etc., feel free to email them to that bug
<dsmith-work>I will.
<dsmith-work>All the backtraces are useless. :(
<dsmith-work>And gdb doesn't even let me disassemeble at the failed address.
<dsmith-work>(gdb) disassemble /r 0x75106c26
<dsmith-work>No function contains specified address.
*dsmith-work shakes fist at gdb
<wingo>you can disassemble 0x75106c26+100
<sneek>Welcome back wingo, you have 1 message!
<sneek>wingo, dsmith-work says: So is there any advantage to calling scm_gc_free() in jit_free_fn() ?
<wingo>like disassembly a byte range
*RhodiumToad returns from power failure
<dsmith-work>(gdb) disassemble /r 0x75106c26+100
<dsmith-work>No function contains specified address.
<RhodiumToad>comma before the +
<dsmith-work>I was sure I did that yesterday.
<dsmith-work> 0x75106c22: 4f f0 00 2c mov.w r12, #0
<dsmith-work>=> 0x75106c26: 4c f8 00 5e strt r5, [r12]
<dsmith-work>Our old frind
<RhodiumToad>yeah. I'm trying an assert in ldi_i to see if it gets hit
<dsmith-work>wingo: Can you explain or point me to some docs/code on how stacks happen with jited code? How they grow and are cleaned up and how they are swithched?
<wingo>dsmith: basically the scheme stack is entirely separate from c
<wingo>it is a data structure that can grow either by remapping or copying. any time the scheme stack might expand (generally at function entry) it might relocate
<wingo>the interpreter operates on the stack as a data structure and doesn't recurse on the C stack, unless it needs to call out to C
<wingo>if a function has JIT code, the interpreter will call the JIT code, which does the same operations on the scheme stack as the interpreter would
<wingo>and when it reaches a function that has no JIT code, either in a call or in a return, it returns back to the interpreter, which reloads the state of the data structure and continues operating
<wingo>all the bits in jit.c and vm-engine.c that reload e.g. SP from the thread are sometimes about register spilling, but often about this need to account for invalidated SP because the stack expanded
<wingo>SP in the logical sense of scheme
<wingo>not %rsp or whatever
<wingo>because remember, two stacks
<wingo>the c stack and the scheme stack.
<RhodiumToad>I think the question behind the question is "why don't backtraces work in gdb when a call came from jitted code"
<RhodiumToad>and I think the answer to that is that the jitted code lacks the debug info needed for gdb to figure that out.
<dsmith-work>Yeah, that's probably true.
*civodul pushes cross-compilation bug fix
<civodul>hey wingo
<wingo>heya :)
<RhodiumToad>I think it's moot anyway. generating mov #0 followed by a load/store using that register indicates something wrong in code generation, not at runtime
<civodul>wingo: you're also OK with releasing as is?
<dsmith-work>The segfaults are often: set r12 to zero, load some reg with [r12]
<wingo>civodul: yes, fixes can always come in a followup
<RhodiumToad>did the rotate_left thing get fixed?
<wingo>sounds like RhodiumToad has a nice ARMv7 fix tho that might make sense to land
<wingo>RhodiumToad: link?
<RhodiumToad>I didn't post it anywhere, sec
<RhodiumToad>what I did was but that's not necessarily the only fix or even the best one
<RhodiumToad>using (v << n | v >> ((32 - n) & 31)) would be another fix
<RhodiumToad>basically, when v is 32 bits as it is here, (v >> 32) is undefined
<dsmith-work>Or (n?(v << n | v >> (32 - n)):v)
<wingo>RhodiumToad: what name and/or email should i use to thank you? :)
<RhodiumToad>Andrew Gierth, andrew at tao11 . riddles . org . uk
<dsmith-work>wingo: While you are here, what's with #define jit_ldrt_strt_p() 0
<dsmith-work>and then many if (jit_ldrt_strt_p() && ...)
<dsmith-work>So effectivly always disabling that branch of the if
<wingo>dsmith-work: it comes from lightning. either i need to detect a feature and use that, or i need to constant-fold it to 1 or 0
<RhodiumToad>we were wondering why it generates ldrt / strt insns despite there being no obvious reason to do that
<civodul>wingo: ah cool, let's include the fix by RhodiumToad
<wingo>doing it now
<dsmith-work>wingo: And another thing. ;^} memset in reset_literal_pool() seems to be a noop.
<wingo>will merge when the test succeeds
<wingo>dsmith-work: why is it a noop?
<dsmith-work>pool->size = 0; memset(pool->entries, 0, sizeof(pool->entries[0]) * pool->size);
<RhodiumToad>third arg is always 0
<wingo>haha yes
<dsmith-work>Maybe should have been ->capacity instead?
<dsmith-work>The rest of the code doesn't touch entries unless the have been initialzed first.
<dsmith-work>So not really a problem. But still..
<wingo>yeah i think i was being paranoid about struct holes and related things
<wingo>a lot of invariant-asserting code there anyway
<dsmith-work>So the errors are trying to dreference NULL. Why? Is the code being generated incorectly? Or is something funky going on at a higher level, passing a zero.
<dsmith-work>That's an immediate 0
<RhodiumToad>this is why I'm trying it with an assertion in ldi_i
<dsmith-work>That should provide a valid backtrace
<RhodiumToad>if something tries to generate a load from address 0, it should fail. but this problem doesn't reproduce reliably for whatever reason
<RhodiumToad>it hasn't failed for me yet. though the power failure I had earlier was in the middle of a run
<dsmith-work>It's address dependant somehow.
<RhodiumToad>dsmith-work: do you get it repeatably with aslr and threads off?
<wingo>civodul: done
<dsmith-work>It always fails a certain test with make check, but NOT when running that individual test
<civodul>wingo: thanks!
<RhodiumToad>dsmith-work: can you put ASSERTs into ldi_i and sti_i to assert that i0 is not 0?
<civodul>wingo: i'll run some more tests, update GUILE-VERSION, and go ahead
<dsmith-work>RhodiumToad: Added the asserts, but I still don't get a backtrace. Looks like they were not asserted.
<RhodiumToad>but you got a crash still?
<RhodiumToad>oh, also add one to sti_c
<dsmith-work>It's the 00-initial-env.test that triggers it.
<dsmith-work>Same. :(
<RhodiumToad>uh. weird.
<RhodiumToad>what's the surrounding code to your crash at runtime?
<dsmith-work>#0 0x75106c26 in ?? ()
<dsmith-work>#1 0x76f556c0 in scm_i_string_ref (str=<optimized out>, x=478720) at strings.c:668
<dsmith-work>#2 0x00074e00 in ?? ()
<dsmith-work>Dump of assembler code from 0x75106c22 to 0x75106c2c:
<dsmith-work> 0x75106c22: 4f f0 00 2c mov.w r12, #0
<dsmith-work>=> 0x75106c26: 4c f8 00 5e strt r5, [r12]
<dsmith-work> 0x75106c2a: 47 f2 f8 45 movw r5, #29944 ; 0x74f8
<RhodiumToad>go back a few more instructions
<dsmith-work> 0x75106c18: 00 5c ldrb r0, [r0, r0]
<dsmith-work> 0x75106c1a: 5c f8 00 5e ldrt r5, [r12]
<dsmith-work> 0x75106c1e: 85 60 str r5, [r0, #8]
<dsmith-work> 0x75106c20: 85 68 ldr r5, [r0, #8]
<dsmith-work> 0x75106c22: 4f f0 00 2c mov.w r12, #0
<dsmith-work> 0x75106c12: 47 f2 d8 4c movw r12, #29912 ; 0x74d8
<dsmith-work> 0x75106c16: c7 f2 00 5c movt r12, #29952 ; 0x7500
<dsmith-work> 0x75106c1a: 5c f8 00 5e ldrt r5, [r12]
<dsmith-work> 0x75106c1e: 85 60 str r5, [r0, #8]
<dsmith-work> 0x75106c20: 85 68 ldr r5, [r0, #8]
<dsmith-work> 0x75106c22: 4f f0 00 2c mov.w r12, #0
<dsmith-work>=> 0x75106c26: 4c f8 00 5e strt r5, [r12]
<RhodiumToad>what assert exactly did you put where?
<dsmith-work>in the three funcs you mentioned
<dsmith-work>ldi_i, sti_c, sti_i
<RhodiumToad>oh interesting
***jonsger1 is now known as jonsger
<RhodiumToad>ok, I have to stare at the manual a while to figure this out
***apteryx_ is now known as apteryx
<civodul>now to debug a deadlock with open-input-output-pipe
<civodul>regtur: if you're around, it's tests/inferior.scm in Guix that triggers it :-)
<RhodiumToad>that mov.w looks like it is invalid.
<RhodiumToad>the imm12 constant is 0010 0000 0000
<RhodiumToad>and the reference manual says that's UNPREDICTABLE
<RhodiumToad>oh FFS
<RhodiumToad>civodul / wingo, if you're planning a release or anything, stop now
<RhodiumToad>I think I found it, one of the paths through encode_thumb_immediate is _completely_ bogus
<dsmith-work>Oh, that's a beauty of a function. Lots of hex everywhere
<RhodiumToad>the case for abcdefgh 00000000 abcdefgh 00000000 will always generate 0, regardless of the input value
<RhodiumToad>the return should be return (((v & 0x0000ff00) >> 8) | (2 << 12));
<RhodiumToad>(it is obvious that (v & 0xff) is 0 because it literally just checked that)
<RhodiumToad>this is why it fails randomly with aslr, because that makes the top bits of the value variable; the success/fail based on whether or not it's run from make might be dependent on the environment size or similar
<RhodiumToad>dsmith-work: can you test that too?
<dsmith-work>Build done
<dsmith-work>Nice find, BTW
<RhodiumToad>this thumb instruction encoding stuff is pretty crazy
<dsmith-work>Flew through the always-fail case
<dsmith-work>SO it was enocoding some valid address as 0.
<RhodiumToad>yup. but only when the valid address was in the form xx00xx00 where both xx were the same.
<dsmith-work>That had to have a specific pattern
<RhodiumToad>so you can see that with aslr, it'd be highly unpredictable
<dsmith-work>And with threshold=0 more opportunities for that to happen
<dsmith-work>Well, failed, But that was
<dsmith-work>Running 00-repl-server.test
<dsmith-work>ERROR: 00-repl-server.test: repl-server: simple expression - arguments: ((misc-error #f "~A" ("Unable to create directory in /tmp for 00-repl-server.test") #f))
<dsmith-work>running again after cleaning /tmp
<dsmith-work>Looks *really* good
<dsmith-work>That's just crazy that XX00XX00 or 00XX00XX would have a sepecial encoding.
<RhodiumToad>well you can sort of see it, in that there's only 12 bits available to use, and they want to represent as many as possible of the actual constants people might want
<RhodiumToad>so e.g. there are ways to encode 0xaaaaaaaa or 0x00010001
<dsmith-work>"Ooo look. Lot's of people use 0xDEADBEEF, let's make a special code for that..."
<mwette>needle in a haystack bug
<dsmith-work>All tests pass
<RhodiumToad>think about the sorts of values that get used as bitmasks, for instance
<mwette>super awesome guys
<RhodiumToad>(there actually _isn't_ a good way to encode 0xdeadbeef in this scheme)
<dsmith-work>Heh, ya. Was attempting humor.
<dsmith-work>So if bit x is set, then bits yz select one of these 4 constants. 0xDEADBEEF ...
<dsmith-work>Hmm. There ought to be some test in the lightening repo that validates all that.
<RhodiumToad>clearly there should be, but equally clearly there is not
<dsmith-work>s/all that/all that immediate encoding/
<janneke>i heard somenoe prefers 0xCABBA9E nowadays
<dsmith-work>Ya. That's fixed it.
<RhodiumToad>been a good week for weird memory bugs
<dsmith-work>civodul: This will close
<civodul>oh, nice!
<civodul>RhodiumToad: could you email what you have to
<civodul>yes, take your time :-)
<RhodiumToad>why do you allow trailing whitespace in your files, btw? it really messes up my diffs
<dsmith-work>Maybe because which comes from ?
*civodul not sure what that statement implies :-)
<RhodiumToad>magit to the rescue, as usual
<RhodiumToad>mail sent
<civodul>thank you, RhodiumToad!
<dsmith-work>civodul: I'm guessing guile inherited the whitespace from lightening which inerited it from lightning. Just a guess.
<civodul>wingo: so we have another lightening patch for ARM by RhodiumToad at
<dsmith-work>One more small nit
<dsmith-work>$ grep JIT_NEEDS_LITERAL_POOL lightening.c | sort| uniq -c
<dsmith-work> 1 #endif // JIT_NEEDS_LITERAL_POOL
<dsmith-work> 12 #ifdef JIT_NEEDS_LITERAL_POOL
<dsmith-work> 1 #if JIT_NEEDS_LITERAL_POOL
<dsmith-work>THat #if should really be #ifdef
<RhodiumToad>oh, there's a small bug in the configure script somewhere
<RhodiumToad>I _think_ it gets here: if test $gl_cv_func_working_mktime = no; then without gl_cv_func_working_mktime being set at all
<RhodiumToad>the failure is probably harmless
<dsmith-work>RhodiumToad: Check out tests/ldr_i.c in the lightening repo. Looks could be easily extended for the failure case (and others).
<apteryx>refining my minimal repro: (guard (c ((message-condition? c) (format #t "error: ~a~%" (condition-message c)))) (throw 'system-error "canonicalize-path" "~A" '("No such file or directory baba"))) -> error: ~A
<apteryx>shouldn't condition-message be able to extract the message from such a throw?
<apteryx>perhaps I need to read the source of make-exception-from-throw
<apteryx>OK, so the error happens in (ice-9 exceptions): (guile-system-error-converter 'system-error '("canonicalize-path" "~A" '("No such file or directory") '(2))) -> $4 = #<&compound-exception components: (#<&external-error> #<&origin origin: "canonicalize-path"> #<&message message: "~A"> #<&irritants irritants: (quote ("No such file or directory"))>)>
<apteryx>we can see that already at that point the message is lost
<apteryx>is this by design? Is it left to the users to correctly format the message doing something like (apply format `(#f ,msg ,@msg-args)) ?
<apteryx>or should the exception object message slot already be populated with a correctly formatted message?
*apteryx has too many questions
<mwette>aperytx: haha - yeah, i don't like the return of "error"; I usually use something like (catch 'ctx (lambda () (throw 'ctx "error ~S ~S ~S" 1 2 3)) (lambda (key fmt . args) (apply simple-format #t fmt args)) if that helps
<apteryx>mwette: the glue in (ice-9 exceptions) seem to provide an opportunity to rectify this if we want
<apteryx>it bridges legacy throw exceptions with srfi-34 style ones
<apteryx>it it typical for a system-error to contain "~A" as the message, and the actual message as a message-argument?
<apteryx>if it's always true, we can format the actual error message at the level of guile-system-error-converter
<apteryx>the node 7.2.1 POSIX Interface Conventions hints that this is the case, with a handler example binding the variables "fmt fmtargs data".
<apteryx>and formatting a human readable message with: (apply format #t fmt fmtargs)
<apteryx>I'll propose a patch.
<dsmith-work>RhodiumToad: ^^
<dsmith-work>Not sure how the api works. But that fails without your fix, and passes with it.
<dsmith-work>civodul: ^^
<dsmith-work>Should be extended with more cases somehow.
<dsmith-work>(I called it movi.c)
<apteryx>the docstring at SCM_DEFINE (scm_error_scm, "scm-error", 5, 0, 0, (error.c, line 70) gives me confidence that we should format the message before raising the exception.
<mwette>apteryx: you mean via (format #f ...) ?
<mwette>I would prefer to have error accept format string and args.
<apteryx>try this for example: (guard (c ((message-condition? c) (format #t "message: ~a~%" (condition-message c)))) (canonicalize-path "/doesntexist"))
<apteryx>it produces: message: ~A: ~S
<apteryx>I'm not sure where that ~S came from
<mwette>i have not looked into SRFI-35 etc. This info in TSPL may apply:
<apteryx>They describe what msg and irritants should be: msg must be a string and should describe the exceptional situation. The irritants may be any Scheme objects and should include values that may have caused or been materially involved in the exceptional situation.
<apteryx>describe the exceptional situation: I don't think "~A" fits the bill ;-).
<civodul>dsmith-work: would be a unit test, right?
<civodul>can you email it to the bug?
<civodul>i don't feel confident with merging the lightening patches so i would prefer to let wingo take a look
<RhodiumToad>that test would presumably go in the tests/ subdir of wingo's lightening repo
<dsmith-work>Yeah, that would be a lightening test.
<dsmith-work>Really should test more cases. But I havn't figured out how yet.
<dsmith-work>And it's more of an example for someone with paperwork to write a real test.
<dsmith-work>civodul: Yes, I'll email it to the bug
<civodul>i don't know how much has diverged but perhaps there are applicable bug fixes in lightning.git
<dsmith-work>mail sent
<dsmith-work>apteryx: There were some recent changes to exceptions and conditions. Looks like more to come too. See NEWS
<dsmith-work>NEWS "Reimplementation of exceptions"
<RhodiumToad>civodul: no, the upstream has the bug too
<RhodiumToad> -- see line 1158
<dsmith-work>Bah. left a printf in that example.
<dsmith-work>Would be nicer if those ASSERTs printed out something instead of just calling abort()
<dsmith-work>Oh! that's lightning, not lightEning
<dsmith-work>Probably some very unexplained things going on there too.
<RhodiumToad>I was looking for the origin of the code and whether it had been fixed elsewhere
***Guest59015 is now known as nalkri
***drakonis1 is now known as drakonis
<dsmith-work>Hmm. The assert *does* print stuff. Just not the actual return value.
<mwette>lightening @; lightning @
<RhodiumToad>grr. coredump running tests
<RhodiumToad>this doesn't look like a jit thing tho
<rekado>apteryx: you’ll find the ~A here: (catch #t (lambda () (canonicalize-path "/doesntexist")) (lambda args args))
<rekado>that gives you (system-error "canonicalize-path" "~A" ("No such file or directory") (2))
<RhodiumToad>=> 0x21f97030 <+348>: vst1.32 {d16-d17}, [r3]!
<RhodiumToad>r3 = 0
<RhodiumToad>#0 0x21f97030 in compare_u32_strings_ci (s1=0xbcd2b6d0, s2=<optimized out>, locale=<optimized out>, func_name=<optimized out>)
<RhodiumToad> at i18n.c:863
<dsmith-work>RhodiumToad: That is supposed to save all those registers at *r3++ right?
<RhodiumToad>it's doing a memory to memory copy using the vector regs
<RhodiumToad>I think this is the for loop in SCM_STRING_TO_U32_BUF
<dsmith-work>So this is clang generated code?
<RhodiumToad>c_str = c_str_malloc_p ? malloc (bytes) : alloca (bytes);
<RhodiumToad>notice no check for NULL return from malloc
<dsmith-work>I've heard that "malloc can't fail on Linux" too many times.
<RhodiumToad>and yup, definitely looks like that's what happened
<RhodiumToad>it tried to allocate 4000000 bytes
<RhodiumToad>hm, it should have been able to do that
<dsmith-work>I've been learning Rust lately, and I've been appreciating it more and more.
<RhodiumToad>fascinating how clang vectorizes that loop, though
<dsmith-work>I guess the safest thing to do there is conditionalze the loop on c_str, and then check it at the call sites.
<dsmith-work>I was really amazed the other day how rust optimized match foo {'Y'|'N'|'y'|'n' => true, _ => false }
<dsmith-work>After adjusting an offset, loaded a bitmap into a regiser and probed that.
<dsmith-work>Only one branch.
<dsmith-work>RhodiumToad: was it a specfic test that failed or another "random" one.
*RhodiumToad runs it again to see
<RhodiumToad>I'd just done a make check at top level, nothing special
<rekado>davexunit: the r/guile community on Guile is restricted so I can’t post there. Is this on purpose?
<RhodiumToad>seems to fail consistently in the same place
<terpri_>dsmith-work, something like this, or is rust cleverer? (that's from gcc -O3, i'm not good at reading amd64 asm though)
<dsmith-work>terpri_: Like
<dsmith-work>Maybe if you swapped the true/false it would be closer
<dsmith-work>That bitmap is the same I think.
<dsmith-work>8800387991553 is 0x80100000801
<RhodiumToad>clang generates a bt rather than the shift/and
<dsmith-work>RhodiumToad: bt ?
<terpri_>with the true false swap and changing the return type to bool i get:
<RhodiumToad>bt = bit test
<terpri_>slightly shorter, but not as concise as the rust asm
<dsmith-work>I was just amazed at the bitmap in a register. Not used to regs with that many bits.
<terpri_>ah yes, good old godbolt
<RhodiumToad>hm. is guile doing its own malloc?
<RhodiumToad>ugh, it's getting it from libgc, isn't it
<dsmith-work>A friend of mine challenged me to write that with no branches. (Because of course, you need to respond in sub-nanoseconds after waiting for a keypress)
<RhodiumToad>bah, trivial with cmov
<dsmith-work>RhodiumToad: alloca or malloc? (why would it need malloc?)
<terpri_>RhodiumToad, i don't think so. guile does have a fallback malloc implementation from gnulib though, it seems
<RhodiumToad>why wouldn't it need malloc?
<RhodiumToad>libgc provides a GC_malloc
<dsmith-work>Sorry. I thought you meant someting else.
<RhodiumToad>but the code in question seems to be calling the bare libc malloc
<dsmith-work>That code allocs and frees right after. No need to get the GC involved. (I assume)
<RhodiumToad>so the question is why did it fail to allocate a mere 4 megs
<terpri_>but if malloc fails...SIGSEGV
<dsmith-work>RhodiumToad: I meant, wny need malloc from gnulib? (not libgc) Is't the c lib malloc good enough?
<terpri_>dsmith-work, i don't know under which circumstances it would *use* gnulib malloc, just that it exists in the repo (lib/malloc.c)
<dsmith-work>Hmm. Special cases size 0.
<RhodiumToad>FAIL: r6rs-ports.test: 8.2.7 Input Ports: custom binary input port position, long offset - arguments: (expected-value 4398046511104
<RhodiumToad>actual-value 0)
<RhodiumToad>wtf is with that
<terpri_>aha: (from lib/
<terpri_>i wonder where malloc isn't posix-compliant. maybe ancient *nix systems or windows or something
<RhodiumToad>that looks like the test is wrong
<RhodiumToad>hm. no.
<terpri_>here's the rub, i think: "If the size of the space requested is 0, the behavior is implementation-defined: either a null pointer shall be returned, or the behavior shall be as if the size were some non-zero value, except that the behavior is undefined if the returned pointer is used to access an object."
<terpri_>but on windows: "If the size of the space requested is 0, the behavior is implementation-defined: either a null pointer shall be returned, or the behavior shall be as if the size were some non-zero value, except that the behavior is undefined if the returned pointer is used to access an object."
<dsmith-work>0075b7f4dc Ludovic Courtès 2018-07-19
<dsmith-work>civodul added that test
<terpri_>"If size is 0, malloc allocates a zero-length item in the heap and returns a valid pointer to that item." is the windows behavior i meant to quote
<terpri_>hence its presence in gnulib, i guess
<dsmith-work>RhodiumToad: So on your system, is that malloc really returning 0? Is there a limit to the amount you can request?
<RhodiumToad>as far as I can tell it returned 0. I don't know why.
<terpri_>your system does have more than 4 megs of memory, right? :D
<RhodiumToad>it's not close to any system limits
<RhodiumToad>1GB ram, per-process limit 512MB
<RhodiumToad>but I'm looking at another failure now
<RhodiumToad>something's assuming that (port-position) should truncate to 32 bits
<dsmith-work>Modern malloc typically uses mmap for largish allocations.
<RhodiumToad>this looks like broken largefile idiocy
<dsmith-work>32bit or 64bit ?
<RhodiumToad>typedef long int scm_t_off; idiocy, I say
<dsmith-work>r6rs and str ports check for base > SCM_T_OFF_MAX, which could be INT64_MAX, INT_MAX, or LONG_MAX.
<dsmith-work>Depending on ./configure
<dsmith-work>INT_MAX is 32bits on a bit system?
<RhodiumToad>what generates scmconfig.h ?
<dsmith-work>Prob libguile/gen-scmconfig.c
<RhodiumToad>oh nonsense
<RhodiumToad>#if defined GUILE_USE_64_CALLS && defined HAVE_STAT64
<RhodiumToad>no comprehension that platforms exist that don't have idiot largefile breakage
<RhodiumToad>on freebsd, as with all *BSDs since around the 4.4BSD period, off_t is 64-bits and there are no silly *64 system calls
<RhodiumToad>that should be checking SIZEOF_OFF_T instead
<RhodiumToad>lack of largefile breakage is one of my favourite freebsd features :-)
<dsmith-work>It's been about 19 years since I used fbsd. Really enjoyed how the drivers and man pages and stuff was all in sync. Nice clean code too.
<dsmith-work>Took me an afternoon to hack up a scsi scanner.