<abu[7]>
I meditated on the situation again. I think it in not correct what LLVM compiled from my *.ll files
<abu[7]>
There seems an assumption that %rsp and %rbp are in sync, but it does not notice that %rsp was changed
<abu[7]>
I hope we are on the safe side now
<tankf33der>
tested
<tankf33der>
debian, llvm 8,13,15,16,18,19 - opt1-3 - ok
<abu[7]>
Supi!
<abu[7]>
So let's stay with this version
<tankf33der>
ok
<abu[7]>
Will release to Debian and PilBox end of this month
rob_w has joined #picolisp
<abu[7]>
Thanks a big lot tankf33der!
<tankf33der>
o/
<tankf33der>
solaris, sparc, big endian did not helped
<tankf33der>
bus erros, coredump
<abu[7]>
Uh
<abu[7]>
Which test?
<tankf33der>
(co 'a 123)
<abu[7]>
Clueless
<abu[7]>
Worked before on sparc?
<tankf33der>
never
<abu[7]>
So perhaps a different problem, coroutine stack handling in general
<tankf33der>
on bigendian
<abu[7]>
@doc/structures "Stack grows downwards" is satisfied?
<tankf33der>
do not ask, i know nothing about this abstractions
<abu[7]>
So coroutines *never* worked there?
<tankf33der>
never
<abu[7]>
Endianess should not matter I think
<tankf33der>
ok
<abu[7]>
Other things except coroutines work?
<tankf33der>
almost, can not test, because pil can not load *.so files
<abu[7]>
Right
<tankf33der>
can not test, because stack can not grow
<abu[7]>
Would be interesting to know what exactly fails, but probably not worth the effort
<tankf33der>
yea
<tankf33der>
stopped
<abu[7]>
ok
<tankf33der>
the same issue on linux bigendian, s390x, for example
<abu[7]>
I see, so big endian fails somewhere
<abu[7]>
probably also Arm64 if big endian
<tankf33der>
yeap
<tankf33der>
FYI
<abu[7]>
We don't even know if LLVM is fully debugged on such exotic systems
<tankf33der>
yeah
<abu[7]>
We should recommend PicoLisp as the standard test suite for LLVM on different platforms
<abu[7]>
"Does it run PicoLisp?"
<tankf33der>
never seen before
<tankf33der>
what is it ?
<abu[7]>
If PicoLisp runs correct on some platform, that platform's LLVM is good ;)
<tankf33der>
only if you fix bigendian, then linux is ok
<abu[7]>
I don't know what the problem (if any) with big endian is. base.ll has no concept of that. So it may be LLVM's fault ;)
<abu[7]>
Can you find out what exactly goes wrong?
<tankf33der>
you said about llvm fault about last co problem
<tankf33der>
too
<abu[7]>
I said that LLVM is not correct on x86 probably
<abu[7]>
%rbp handling
<abu[7]>
Or what did you mean?
<tankf33der>
Never mind
<tankf33der>
afk
<abu[7]>
Or what did you mean?
Guest70 has joined #picolisp
Guest70 has quit [Client Quit]
<tankf33der>
back
<abu[7]>
Cheers
<tankf33der>
I believe that I also contributed to fixing this glitch because I insisted that LLVM itself should work correctly. It is good that you did not give up on fixing it and found the bug.
<abu[7]>
Yes, you contributed a big part. You found several bugs and missing runtime checks, and fixing these revealed a fundamental problem.
<abu[7]>
In was there for years
<tankf33der>
I am glad that everything is over. I will have a good and relaxing vacation.