Displaying 3 results from an estimated 3 matches for "99670".
Did you mean:
9967
2010 Dec 03
1
[LLVMdev] Alternative exception handling proposal
...ntly labeled a "horrible hack".
Sorry for the nasty name. But you've got to admit that it's not beautiful, and
I have to admit that it solved a real problem.
It
> must work flawlessly with your new proposal.
>
> http://llvm.org/viewvc/llvm-project?view=rev&revision=99670
> <http://llvm.org/viewvc/llvm-project?view=rev&revision=99670>
>
> int main() {
> try {
>
> throw new std::exception();
> } catch (std::exception *e) {
> throw e;
> }
> }
Here's the IR with my scheme ("auto-generated&quo...
2010 Dec 02
0
[LLVMdev] Alternative exception handling proposal
...netheless it does!).
>
John all ready mentioned problems with your inlining proposal. Here is the code that brought up the need for what you instantly labeled a "horrible hack". It must work flawlessly with your new proposal.
http://llvm.org/viewvc/llvm-project?view=rev&revision=99670
int main() {
try {
throw new std::exception();
} catch (std::exception *e) {
throw e;
}
}
And this code needs to give a sensible backtrace (on Darwin at least). It will crash libunwind because it was doing horrible things:
#import <Foundation/Foundation.h>
int m...
2010 Dec 02
3
[LLVMdev] Alternative exception handling proposal
Hi Bill,
> This is similar to my first proposal.
yup, I still consider your first proposal to have been basically sound.
But it also suffers from a major problem,
> which stopped that proposal dead in its tracks. Namely, you have information in
> one place which needs to be shared in two different, but possibly disjoint,
> places: the type, filters, and personality information. In