ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: https://irclog.whitequark.org/picolisp/ | Check also http://www.picolisp.com for more information
LamBaah has joined #picolisp
LamBaah has quit [Client Quit]
GrayArea has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 246 seconds]
<Regenaxer> Still a bug in tty handling in pil21
<Regenaxer> if a child process reads from tty
<Regenaxer> I have that in a REPL in GUI child process
<Regenaxer> when the process times out
<Regenaxer> Can also be reproduced with this:
<Regenaxer> $ bin/picolisp -'unless (fork) (char)' -bye
<Regenaxer> Needs an "stty sane" after that
<Regenaxer> Must have something to do with readline
<Regenaxer> Must be some signal issue
<Regenaxer> Problem is that strace does not help
<Regenaxer> when strace'd, the issue disappears
orivej has joined #picolisp
<Regenaxer> ok, changed terminal reset a little. Now for GUI children it is ok
<Regenaxer> But not for the unless (fork) case
<tankf33der> i am worried about llvm12 issue, we could ignore until it became release candidate or spent time now. i could write to llvm-dev ml, but they will not understand me and issue.
<Regenaxer> I think better find the reason
<Regenaxer> could be something fundamental
<Regenaxer> just by chance not showing in other versions
<Regenaxer> The crash is in heap operations
<Regenaxer> So what exactly is wrong?
<Regenaxer> is the heap *sometimes* not aligned?
<Regenaxer> e.g. after the second block is malloc()ed
<Regenaxer> Did you try valgrind etc.?
<Regenaxer> btw, how do you type with your repaired shoulder?
<tankf33der> fingers are working
<tankf33der> i will post here my llvm progress
<tankf33der> leaving the hospital
<Regenaxer> Good news!
<tankf33der> http://ix.io/2Lir
<tankf33der> Regenaxer: two runs on different llvms
<tankf33der> first: llvm11 stable
<tankf33der> last: night build snapshot
<tankf33der> both runs under valgrind of course
orivej has quit [Ping timeout: 256 seconds]
<Regenaxer> interesting!
<Regenaxer> Why two runs? I see only one
<Regenaxer> anyway some argument to eval in stem it seems
<Regenaxer> err
<tankf33der> two runs with multi newline separator
<Regenaxer> "equal" I meant
<Regenaxer> ah
<tankf33der> do you see text after first two lines?
<Regenaxer> no
<tankf33der> refresh, should be
<Regenaxer> Perhaps cause I'm in w3m
<Regenaxer> anyway 'stem' -> 'equal'
<Regenaxer> ah, empty, same in w3m
<tankf33der> ok
<tankf33der> first two lines from llvm11, no warnings, see
<Regenaxer> yeah, understand
<tankf33der> so
<Regenaxer> But how can it be different?
<tankf33der> because llvm12 generates that code, i belive in wrong backend
<Regenaxer> only relevant line is (equal (car L) (car P))
<Regenaxer> Which arg is wrong, and why is the question
<Regenaxer> or this line fails (? (atom (shift L)))
<Regenaxer> pointer/alignment etc
<Regenaxer> so it reads nonsense from the heap
<tankf33der> i could try to ask on irc or here:
<Regenaxer> Not sure, it is difficult to ask so that the problem is understood by non-PicoLispers ;)
<Regenaxer> Perhaps post a fragment of the .ll code?
<Regenaxer> Or debug the code
<Regenaxer> http://ix.io/2LiC
<Regenaxer> then call stem manually
<Regenaxer> shows the values passed to 'equal'
GrayArea has joined #picolisp
<tankf33der> asked on irc, on oftc server, #llvm
<Regenaxer> ok
<Regenaxer> tankf33der, when will you be home?
<tankf33der> Regenaxer: already home
<Regenaxer> Great!
<tankf33der> no good answers on irc from llvm
<Regenaxer> I thought so
<Regenaxer> did you try (dbg ...)?
<Regenaxer> To trace down what exactly goes wrong
GrayArea has quit [Ping timeout: 272 seconds]
<tankf33der> i built pil21 with memory sanitizer and got always different warnings, but silence on llvm11
<beneroth> weird stuff
GrayArea has joined #picolisp
<Regenaxer> What is the output of (dbg ...)s?
<Regenaxer> Experiment with various locations
<Regenaxer> (cd src; make) && ./pil -'msg (stem (chop "abc/def\\ghi") "/" "\\")' -by
<Regenaxer> tests in quick succession from bash history
<Regenaxer> That's how I search for such bugs
<Regenaxer> s/-by/-bye
<tankf33der> llvm11 fails now under msan
<tankf33der> switch to dec13 branch and it is ok
<Regenaxer> We really need to know *what* goes wrong *where*
<Regenaxer> on a system where it is reproducible
<tankf33der> http://ix.io/2LjU
<tankf33der> this is llvm11
<Regenaxer> Perhaps simpler data like (stem (1 2 3) 2)
<Regenaxer> The crashes are all only symptoms of some deeper problem
<Regenaxer> As you seem to reproduce it in llvm12, you should find the exact problem there
<tankf33der> this is llvm11
<tankf33der> pil21 is broken
<Regenaxer> anyway
<Regenaxer> valgrind passes here on llvm12/Debian
<Regenaxer> oops
<Regenaxer> llvm11/Debian I mean
<tankf33der> bisect found problem started from this commit
<Regenaxer> What do you mean with "bisect"?
<tankf33der> git bisect - i set start and bad range and git do binary search on commits to find where problem started
<Regenaxer> 11dec20 - 14dec20 was the big I/O change
<tankf33der> i think this why llvm12 fails now.
<Regenaxer> yes, but *where* exactly does it go wrong
<Regenaxer> the infos don't help me
<Regenaxer> How did you check with the sanizer?
<tankf33der> CC = clang -fsanitize=memory
<tankf33der> and rebuild.
<Regenaxer> ok
<tankf33der> it could crashes without backtrace too.
<Regenaxer> Can't build on termux
<tankf33der> yea
<Regenaxer> Can build on Debian
<Regenaxer> but then just "bin/picolisp" does not work
<Regenaxer> uninitialized bytes in readline
<Regenaxer> before any Lisp code runs
<Regenaxer> I think this is not usable
<Regenaxer> Why don't you 'dbg' on llvm12? It is where we have a *real* error
DKordic has quit [Ping timeout: 260 seconds]
<tankf33der> because llvm11 fails too if i understands correct
<Regenaxer> Not fails
<tankf33der> how you run it?
<Regenaxer> the checker says something we don't understand
<Regenaxer> (dbg ) is like (msg ) in Lisp
<Regenaxer> you can put it anywhere and compile
<Regenaxer> (cd src; make) && ./pil -'msg (stem (chop "abc/def\\ghi") "/" "\\")' -bye
<Regenaxer> 'dbg' takes a 64-bit integer and a Lisp Item
<Regenaxer> (dbg 7 $T) prints "7 T"
<Regenaxer> (dbg 1 L) prints "1 ("a" "b" .. etc
<Regenaxer> afp under shower
<tankf33der> ============
<tankf33der> llvm12
<tankf33der> ./pil -'msg (stem (chop "abc/def\\ghi") "/" "\\")' -bye
<tankf33der> ("a" "b" "c" "/" "d" "e" "f" "\\" "g" "h" "i")
<tankf33der> =============
<tankf33der> llvm11
<tankf33der> $ ./pil -'msg (stem (chop "abc/def\\ghi") "/" "\\")' -bye
<tankf33der> ("g" "h" "i")
<tankf33der> ========
<tankf33der> so whats the point? how it could help?
<tankf33der> afk
ym has joined #picolisp
<Regenaxer> ret
<Regenaxer> It *must* print something to stderr
<Regenaxer> if you inserted dbg as in the link above
<Regenaxer> http://ix.io/2LiC
<tankf33der> aaaaaaaaaaaaaaaaaaaaa
<Regenaxer> It is where the loop traverses the list
<tankf33der> it make sence
<Regenaxer> either it prints something or crashes if wrong data :)
<Regenaxer> The next line calls 'equal'
<tankf33der> my head still feels bad after surgery
<Regenaxer> this is where I think llvm12 crashed
<Regenaxer> oh :)
<Regenaxer> No hurry
<tankf33der> doing
<tankf33der> 1 ("a" "b" "c" "/" "d" "e" "f" "\\" "g" "h" "i")
<tankf33der> Segmentation fault (core dumped)
<tankf33der> $ ./pil -'msg (stem (chop "abc/def\\ghi") "/" "\\")' -bye
<tankf33der> it crashed this way on llvm11
<Regenaxer> hmm, before printing anything?
<tankf33der> used this diff
<tankf33der> http://ix.io/2LkI
<tankf33der> yea, copy-paste from cli
<Regenaxer> yes, looks good
orivej has joined #picolisp
<tankf33der> really? :)
<tankf33der> then trying on llvm12
<Regenaxer> crashes also if you just : (stem (1 2 3) 2) in repl?
<Regenaxer> Has nothing to do with the version
<Regenaxer> I try here
<Regenaxer> oops
<tankf33der> $ pil21 +
<tankf33der> 1 (1 2 3)
<tankf33der> : (stem (1 2 3) 2)
<tankf33der> Segmentation fault (core dumped)
<Regenaxer> you are right
<tankf33der> llvm11 ^^^
<Regenaxer> wrong call, my mistake
<tankf33der> what is correct then?
<Regenaxer> Just with 'L' it works:
<Regenaxer> $~/pil21 (cd src; make) && ./pil -"stem (1 2 3)
<Regenaxer> 2" -bye +
<Regenaxer> 1 (1 2 3)
<Regenaxer> 1 (2 3)
<Regenaxer> 1 (3)
<Regenaxer> ~/pil21
<Regenaxer> 'P' seems bad (?)
<Regenaxer> yes
<Regenaxer> 'P' is a stack structure
<Regenaxer> try (car P)
<Regenaxer> Printing L and (car P):
<Regenaxer> $~/pil21 (cd src; make) && ./pil -"stem (1 2 3)
<Regenaxer> 2" -bye +
<Regenaxer> 1 (1 2 3)
<Regenaxer> 1 2
<Regenaxer> 1 (2 3)
<Regenaxer> 1 2
<Regenaxer> 1 (3)
<Regenaxer> 1 2
<tankf33der> works
<tankf33der> yea
<Regenaxer> on llvm12 ?
<tankf33der> http://ix.io/2LkO
<tankf33der> this is llvm11
<tankf33der> now llvm12
<Regenaxer> good
<tankf33der> http://ix.io/2LkP
<tankf33der> llvm12
<Regenaxer> (NIL . @)
<Regenaxer> it is the stack structure
<Regenaxer> so the stack is not aligned
<Regenaxer> 'equal' never succeeds
<Regenaxer> that explains it
<Regenaxer> But what exactly is wrong on the stack?
<Regenaxer> Can you try with (dbg A $T)?
<Regenaxer> instead of the other two
<tankf33der> doing
<Regenaxer> 'A' should be the address
<Regenaxer> must be a multiple of 8
<Regenaxer> I thought llvm guarantees to allocate the stack at 64-bit boundaries
<Regenaxer> must check the reference
<tankf33der> http://ix.io/2LkV
<Regenaxer> on Arm64 even the hardware forces this
<tankf33der> llvm12 ^^^
<Regenaxer> yes, 140734108545264 is *not* aligned
<Regenaxer> multiple of 4 but not 8
<Regenaxer> Is there a compile time option?
<Regenaxer> http://ix.io/2LkW
<Regenaxer> from lang ref
<Regenaxer> I must set a layout option
<tankf33der> then you break ortability
<tankf33der> then you break portability
<Regenaxer> no
<Regenaxer> it *needs* 64-bit alignment
<Regenaxer> pil21 would not run at all
<tankf33der> how it works in llvm7+
<tankf33der> ?
<Regenaxer> It was always aligned obviously
<beneroth> so wrong use of llvm which worked, or llvm changed default behavior?
<Regenaxer> I expected it to be a hardware requirement
<Regenaxer> it *is* on Arm64
<Regenaxer> but x86 is more tolerant
<Regenaxer> I cannot find where I set the options
<Regenaxer> forgot
<Regenaxer> meta data in .ll
<Regenaxer> target datalayout
<tankf33der> page 4
<tankf33der> correct
<tankf33der> ooo
<Regenaxer> Must study
<tankf33der> i can generate llvm-ir from simple c file on both lllvms and compare
<Regenaxer> I will insert a "target datalayout" section
<Regenaxer> I thought I had that
<Regenaxer> but omitted
<Regenaxer> example: target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
<tankf33der> i told you about this a year ago :)
<Regenaxer> really?
<Regenaxer> I know I had it
<Regenaxer> but it was not needed
<Regenaxer> we can't assume most of them
<Regenaxer> only 'S' remains probably
<Regenaxer> We should *not* say 'E' or 'e'
<Regenaxer> cause we cannot know
<tankf33der> target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
<tankf33der> target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
<tankf33der> equal for 11 and 12
<Regenaxer> but not for machines with big endian
<Regenaxer> e vs E
<tankf33der> target datalayout = "E-m:e-i64:64-n32:64-S128"
<Regenaxer> this is the full spec:
<Regenaxer> http://ix.io/2Ll4
<tankf33der> sparc, clang10
<Regenaxer> We can o
<Regenaxer> we can use only 'S'
<tankf33der> yea
<Regenaxer> and perhaps 'p'
<Regenaxer> and p must be 64
<Regenaxer> so only 'S' makes sense
<Regenaxer> and I believed it is 64 anyways
<tankf33der> will you release immediatly or give me a line to test before ? :)
<Regenaxer> yes
<Regenaxer> what is -128?
<tankf33der> -S128?
<tankf33der> where you find -128 in three lines?
<Regenaxer> at the end of the example above
<Regenaxer> target datalayout = "64-S128"
<Regenaxer> I would use this
<Regenaxer> but I forgot what the -128 means
<tankf33der> full doc
<Regenaxer> "The layout specification consists of a list of specifications separated by the minus sign character ('-')"
<Regenaxer> thats what I sent above
<Regenaxer> so why 2 values for 'S'?
<Regenaxer> ah
<Regenaxer> it must be:
<Regenaxer> target datalayout = "S128"
<Regenaxer> right?
<tankf33der> trying
<tankf33der> asap
<Regenaxer> hmm, moment
<Regenaxer> I think I know why the layout is not needed
<Regenaxer> I specify an alignment for each 'push'
<Regenaxer> this must go wrong
<tankf33der> eh
<Regenaxer> checking
<Regenaxer> So the .ll does not need a target layout
<Regenaxer> somehow the 'push' in _stem is wrong
<Regenaxer> wrong type?
<tankf33der> unknown
<Regenaxer> ok, sorry, no time now
<Regenaxer> will check tomorrow, ok?
<tankf33der> ok
<Regenaxer> Too tired anyway
<Regenaxer> and you must recover
<tankf33der> :)
<tankf33der> see you
<tankf33der> afk
<Regenaxer> thanks!!
ym has quit [Quit: Leaving]
<beneroth> you are awesome, I thank you both
<beneroth> afk
<Regenaxer> Hmm, can't stop ;)
<Regenaxer> Alignment in push is not always done
<Regenaxer> So I better set a data layout
<Regenaxer> no
<Regenaxer> gives error when linking with code from .c
<Regenaxer> So I change the alignment in 'push'
orivej has quit [Ping timeout: 246 seconds]
<Regenaxer> I released it
<tankf33der> doing
<tankf33der> llvm7 and 11 are ok
<tankf33der> llvm12 fails on stem like before.
<tankf33der> afk.
<tankf33der> sleep.
<Regenaxer> oh
<Regenaxer> ok, tomorrow
<Regenaxer> I was absolutely sure the stack is now aligned to 8 bytes
<tankf33der> then i will dbg again on llvm12 now
<Regenaxer> No, better sleep :)
<Regenaxer> repair your shoulder
<tankf33der> last attempt
<Regenaxer> ok ;)
<tankf33der> 140726631093744 T
<tankf33der> 140726631093744 T
<tankf33der> 140726631093744 T
<tankf33der> ...
<tankf33der> the same 4s
<Regenaxer> I see
<Regenaxer> for 'A'?
<tankf33der> (dbg A $T)
<tankf33der> in loop before equal
<Regenaxer> yeah
<tankf33der> and 4s on llvm11 too
<Regenaxer> is line 89412 in src/base.ll this?
<Regenaxer> %44 = alloca i64, i64 1, align 8
<Regenaxer> ie align 8 ?
<tankf33der> yes
<Regenaxer> Why is it not aligned then?
<tankf33der> yeah
<tankf33der> sleep
<Regenaxer> ok
<Regenaxer> me too
orivej has joined #picolisp
viaken has quit [Quit: reboot]
viaken has joined #picolisp