freenode/#clasp - IRC Chatlog
Search
13:58:16
Bike
drmeister: i'm trying to elide the vaslist construction if it's unneeded. I thought this would be pretty easy because there's already a flag for whether the effective methods need a valist i can use. However, codegen-slot-reader/writer call vaslist-end for some reason. What does it do?
14:00:05
Bike
looks like it does va_end. but i don't see how that would be necessary only for slot readers and writers.
14:00:34
Bike
if it's necessary for anything that doesn't use the vaslist, fast method calls should be doing it too.
14:03:33
Bike
but even for readers and writers it only does it for the instance-slot case. what the heck.
14:04:14
Bike
okay i'm just going to guess it's needed for everything but calls that use the vaslist.
16:56:11
Bike
there seem to be a few dozen call history entries that ought to end up using a method function but don't, and i'm not sure why
16:56:33
Bike
some of them are clos stuff, which is bad but probably just due to some bootstrap shit, but some in quicklisp also
17:01:31
drmeister
Hmmm - do they have anything else special about them? Are they fixed up in fixup.lsp?
17:40:02
Bike
the C++ faq spends quite a lot of time trying to convince the reader that exception handling is better than fucking return codes
17:40:41
Bike
and also doesn't seem to say anything about this issue, so i guess it's not a question frequently asked
17:44:02
Kevslinger
If you slide the first E to the end, you get NO MEMO, which would be the opposite of printf working
17:45:13
drmeister
I really hope that I can implement unwind-protect with C++ exceptions/itanium exception handling. I'm going to be really, really pissed if I can't.
17:45:52
Bike
it does mention "The C++ rule is that you must never throw an exception from a destructor that is being called during the “stack unwinding” process of another exception"
17:46:40
Bike
it might be a more general rule that you can't throw an exception during stack unwinding
17:47:28
Bike
you need to be able to say, okay i'm done unwinding with that exception, instead i'm going to unwind with this other one
17:49:22
drmeister
Well, C++ try/catch/RAII are implemented with itanium exception handling - I might not be able to do it with C++ - but I might be able to finess it with llvm and itanium exception handling if I implement it in llvm-ir.
17:49:42
Bike
like, if you have try ... catch (...) { whatever; throw; } then surely that halts stack unwinding during the catch block
17:52:23
Bike
as i recall, you moved away from it because it didn't seem to be working, perhaps due to some mismatch of manually used itanium exception handling internal calls
17:53:39
drmeister
I have to look at the try {protected();} catch (...) {cleanup(); throw} case and the LLVM-IR that it generates carefully to figure that out.
17:54:17
drmeister
Wait - it goes try {protected();} catch (...) {cleanup(); throw;} cleanup(); case
17:55:44
drmeister
Right now I'm looking at RAII again with the question "how would I fix this so that if the protected form throws an exception and the cleanup form throws an exception - how would I make it work".
17:55:58
Bike
by the way, did you know that the C++ faq says to not use bare pointers in constructors ever due to some confusing fact about exceptions? what is with this language.
17:57:21
drmeister
Not if I use RAII in C++ - but I could write a FUNWIND-PROTECT that would work in raw llvm-ir.
17:58:44
drmeister
RAII generates llvm-ir that handles every case except if both the protected form and cleanup form throw an exception.
18:01:17
Bike
in ir all we want to do is uh, "invoke protected() normally goto 1 otherwise goto 2; 1: cleanup(); 2: landingpad whatever; cleanup(); resume;"
18:08:28
drmeister
https://gcc.godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(j:1,options:(colouriseAsm:'0',compileOnChange:'0'),source:'%23include+%3Cstdio.h%3E%0A%0Along+__attribute__((noinline))+f(long+*l,+double+*d)+%7B%0A++*l+%3D+20%3B%0A++*d+%3D+0.0%3B%0A++return+*l%3B%0A%7D%0A%0Aunion+U+%7B%0A++long+l%3B%0A++double+d%3B%0A%7D%3B%0A%0Aint+main()+%7B%0A++union+U+u%3B%0A++printf(%22%25ld%22,+f(%26u.l,+%26u.d))%3B%0A%7D%0A'),l:'5',n:'1'
18:08:28
drmeister
,o:'C%2B%2B+source+%231',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:clang390,filters:(b:'0',commentOnly:'0',directives:'0',intel:'0'),options:'-S+-emit-llvm+-fno-omit-frame-pointer'),l:'5',n:'0',o:'%231+with+x86-64+clang+3.9.0',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4
18:09:16
drmeister
If I lie to the C++ compiler and say that the cleanup destructor will not throw an exception - then we get llvm-ir that looks like what we want.
18:10:49
drmeister
ACTION did not expect that his entire life work hinged on implementing unwind-protect in llvm-ir.
18:11:46
drmeister
The morality of lying to clang? Or that just calling the Cleanup destructor would work.
19:31:23
drmeister
So the problem is probably that I'm not cleaning up properly when I throw and catch exceptions in cleanup-blocks.
19:41:23
drmeister
It looks more like it's behaving differently when run from within the test macro.
19:47:14
drmeister
Ok - all is well. bclasp fails the caught exception in a cleanup form cclasp works.
19:48:05
drmeister
Yes, it means what we suspected - there is still a problem with caught exceptions in bclasp - but funwind_protect is now working as it should.
19:55:52
Bike
sometimes methods aren't marked as leaves and i don't know why. if i run the defmethod again it fixes itself