<abu[7]>
It must be that I do something illegal around setjmp/longjmp
<abu[7]>
Perhaps I forgot some rule
<tankf33der>
your rules ?
<abu[7]>
No, longjmp
<abu[7]>
Some locals may not be preserved
<abu[7]>
Let me check
<abu[7]>
Reading the man pages again
<abu[7]>
"CAVEATS"
<abu[7]>
"The compiler may optimize variables into registers, and longjmp() may restore the values of other registers in addition to the stack pointer and program counter."
<abu[7]>
I fogot that
<abu[7]>
perhaps violated somewhere
<abu[7]>
I check all places
<tankf33der>
sounds like this
<abu[7]>
T
<tankf33der>
and -O3 will be back :)
<abu[7]>
Hmm ...
<abu[7]>
.
<tankf33der>
afk
<abu[7]>
cu
beneroth_ has joined #picolisp
beneroth has quit [Read error: Connection reset by peer]
<tankf33der>
abu[7]: any updates?
<abu[7]>
No
<abu[7]>
I don't find a way to guarantee the survival of the vars
<tankf33der>
i see
<abu[7]>
Perhaps need do make them "votile", but this requires a major extension of @src/lib/llvm.l
<abu[7]>
What did you find? Is it at least the case that it works everywhere with -O1 h
<abu[7]>
?
<tankf33der>
i did play with some settings but no results
<abu[7]>
ok
<abu[7]>
I'll dig deeper
<tankf33der>
how it worked many years before >
<tankf33der>
?
<abu[7]>
I think by lucky coincidence
<abu[7]>
Variables usage patterns
<tankf33der>
lucky is over, yeah
<abu[7]>
I try to understand it myself ;)
<abu[7]>
If I put (dbg .. var .. it often works
<abu[7]>
or even crashes better
<abu[7]>
Must take a walk and meditate
<abu[7]>
Too hot now though
<tankf33der>
ok
<abu[7]>
At the moment I don't even know *which* variable(s) are destroyed (if it is indeed so), because printing them changes the situation
<abu[7]>
Also, technically I have no case where a var really violates the conditions described in CAVEATS in the man page of setjmp/longjmp
<abu[7]>
So it is possible that I simply have a typo in the source somewhere
<tankf33der>
hm
<abu[7]>
'lint' would find that, but it's hard to use it in the build context