<div dir="ltr"><div><div>Hi Christian,<br><br></div>I am not very familiar with the Mach-O file format, but may you dump the object file generated the JIT compiler pipeline and check their unwind information sections (usually .eh_frame)? Also, compare it with the output generated by the working AOT compiler pipeline. It seems it is possible that the unwind information is not properly generated or handled.<br><br></div>Logan<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 12, 2015 at 1:16 PM, Christian Schafmeister <span dir="ltr"><<a href="mailto:chris.schaf@verizon.net" target="_blank">chris.schaf@verizon.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">This is the only thing that I’ve found that works in terms of getting the exception to propagate out of the JITted function - change the “call” to an “invoke” and hook in the do-nothing landing-pad.<div><br></div><div><a href="https://gist.github.com/drmeister/7a35046f666826206973" target="_blank">https://gist.github.com/drmeister/7a35046f666826206973</a></div><div><br></div><div>Compare line 646 of the file above to the one that I just posted.</div><div><br></div><div><blockquote type="cite"><div style="word-wrap:break-word"><a href="https://gist.github.com/drmeister/b97dec956c6ee9ffeb75" target="_blank">https://gist.github.com/drmeister/b97dec956c6ee9ffeb75</a></div></blockquote></div><div><br></div><div>The first one propagates the exception and the second one fails.</div><div><div class="h5"><div><br></div><div><br></div><div><br></div><div><br><div><div>On Apr 12, 2015, at 1:09 AM, Christian Schafmeister <<a href="mailto:chris.schaf@verizon.net" target="_blank">chris.schaf@verizon.net</a>> wrote:</div><br><blockquote type="cite"><div style="word-wrap:break-word">I’ve tried every reasonable combination of disabling nounwind and enabling uwtable - it doesn’t fix the problem.<div><br></div><div>Here is a copy of the most recent Module with the uwtable attribute attached to cc_call and the function that doesn’t propagate the exception “cl->UNNAMED-LAMBDA”</div><div><br></div><div><a href="https://gist.github.com/drmeister/b97dec956c6ee9ffeb75" target="_blank">https://gist.github.com/drmeister/b97dec956c6ee9ffeb75</a></div><div><br></div><div><br></div><div><br><div><div>On Apr 12, 2015, at 12:58 AM, Christian Schafmeister <<a href="mailto:chris.schaf@verizon.net" target="_blank">chris.schaf@verizon.net</a>> wrote:</div><br><blockquote type="cite"><div style="word-wrap:break-word">Logan,<div><br></div><div>I need to make a correction of the post that preceded this one!<div><br></div><div>I was wrong when I said this:</div><div><blockquote type="cite"><div style="word-wrap:break-word">When I load the bitcode file for this module and then dump it just before it is JITted, the “uwtable” attribute has disappeared - is this prune-eh doing its work even though it’s not listed above in the list of function pass managers?</div></blockquote><br>The “uwtable” attribute does not disappear! I had forgotten to llvm-as the .ll file that I was hand-editing. (I’ve hacked my compiler so that it JITs a module from a bitcode file that I hand edit while I’m trying to sort out whether these attributes can be properly set to avoid the problem that I’m seeing).</div><div><br></div><div>I’m trying different combinations of function attributes to see if that fixes the problem.</div><div><br></div><div>Best,</div><div><br></div><div>.Chris.</div><div><br><div><div>On Apr 12, 2015, at 12:51 AM, Christian Schafmeister <<a href="mailto:chris.schaf@verizon.net" target="_blank">chris.schaf@verizon.net</a>> wrote:</div><br><blockquote type="cite"><div style="word-wrap:break-word">Logan,<div><br></div><div>Thank you very much for the feedback and guidance.</div><div><br></div><div>The passes that I use for JIT compilation are as follows - I don’t see prune-eh in there - could it still be happening?</div><div><br></div><div><div><font face="Courier">(defun create-function-pass-manager-for-compile (module)</font></div><div><font face="Courier"> (let ((fpm (llvm-sys:make-function-pass-manager module)))</font></div><div><span style="font-family:Courier"> (llvm-sys:function-pass-manager-add fpm (llvm-sys:create-basic-alias-analysis-pass)) ;; <<< passes start here</span></div><div><font face="Courier"> (llvm-sys:function-pass-manager-add fpm (llvm-sys:create-instruction-combining-pass))</font></div><div><font face="Courier"> (llvm-sys:function-pass-manager-add fpm (llvm-sys:create-promote-memory-to-register-pass))</font></div><div><font face="Courier"> (llvm-sys:function-pass-manager-add fpm (llvm-sys:create-reassociate-pass))</font></div><div><font face="Courier"> (llvm-sys:function-pass-manager-add fpm (llvm-sys:create-gvnpass nil))</font></div><div><font face="Courier"> (llvm-sys:function-pass-manager-add fpm (llvm-sys:create-cfgsimplification-pass -1))</font></div><div><font face="Courier"> (llvm-sys:do-initialization fpm)</font></div><div><font face="Courier"> fpm))</font></div></div><div><br></div><div>I set things up to add the “uwtable” function attribute to every function that I generate - a current module looks like this: <a href="https://gist.github.com/drmeister/107a84d3d5023ebf13a8" target="_blank">https://gist.github.com/drmeister/107a84d3d5023ebf13a8</a></div><div>On line 617 is the function (now it has the "uwtable" attribute) that is not propagating an exception thrown in cc_call on line 642.</div><div><br></div><div>A couple of questions: the prototype for cc_call on line 559 has the function attribute “nounwind” - I should probably remove that - correct?</div><div><br></div><div>When I load the bitcode file for this module and then dump it just before it is JITted, the “uwtable” attribute has disappeared - is this prune-eh doing its work even though it’s not listed above in the list of function pass managers?</div><div><br></div><div>I feel like there may be multiple things going on, thwarting my attempts to get these functions to propagate an exception.</div><div><br></div><div>Thanks,</div><div><br></div><div>.Chris.</div><div><br></div><div><br><div><div>On Apr 11, 2015, at 11:03 PM, Logan Chien <<a href="mailto:tzuhsiang.chien@gmail.com" target="_blank">tzuhsiang.chien@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><div><div><div>Hi Christian,<br><br></div>Thanks for your explanation. I know your situation now. I would suggest you to check the optimization pass used by the JIT compiler, especially IPO/PruneEH.cpp. It will try to add nounwind attribute to functions which will result in the problem you have mentioned earlier.<br><br></div>Alternatively, as a workaround, try to add uwtable (function attribute) to the functions that are generated by your compiler. This may help as well.<br><br></div><div>Sincerely,<br></div>Logan<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 12, 2015 at 8:49 AM, Christian Schafmeister <span dir="ltr"><<a href="mailto:chris.schaf@verizon.net" target="_blank">chris.schaf@verizon.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Logan,<div><br></div><div>There may be some confusion here because I wasn’t completely clear about what was calling what and where “invoke” appeared to be necessary when I JIT the code and where I realize that “invoke” is absolutely necessary. As far as I understand the Itanium ABI I only need an “invoke” in function A when function B is invoked - the rest of the calls to C() and D() should be able to use “call".</div><div><br></div><div><br></div><div>Here’s an example in C++ (for illustration) and then the identical example in Common Lisp.</div><div><br></div><div>In Common Lisp I can compile individual expressions in the REPL. </div><div>Here is a more illustrative example. If I compile all of these functions ahead of time - everything works fine and D() and C() are called using LLVM “call”.</div><div>But if I JIT these functions one at a time it will fail. If I use llvm “invoke” to JIT the function C() - then the thrown exception will make it to A() and everything works.</div><div><br></div><div><div><font face="Courier">// In C++</font></div><div><font face="Courier">//</font></div><div><font face="Courier">void D() {</font></div><div><font face="Courier"> throw MyException();</font></div><div><font face="Courier">};</font></div><div><font face="Courier"><br></font></div><div><font face="Courier">void C() {</font></div><div><font face="Courier"> D(); // This should be able to be called with “call” </font></div><div><font face="Courier"><span style="white-space:pre-wrap"> </span>// - but if I JIT this function it won’t work - I need “invoke” and a dummy landing pad</font></div><div><font face="Courier">};</font></div><div><font face="Courier"><br></font></div><div><font face="Courier">void B() {</font></div><div><font face="Courier"> C(); // This can be called with "call"</font></div><div><font face="Courier">};</font></div><div><font face="Courier"><br></font></div><div><font face="Courier"><br></font></div><div><font face="Courier">void A() {</font></div><div><font face="Courier"> try {</font></div><div><font face="Courier"> B(); // <<--- This needs to be called with "invoke"</font></div><div><font face="Courier"> } catch ( MyException& e) {</font></div><div><font face="Courier"><span style="white-space:pre-wrap"> </span>/* Do something */</font></div><div><font face="Courier"> };</font></div><div><font face="Courier">};</font></div><div><font face="Courier"><br></font></div><div><font face="Courier"><br></font></div><div><font face="Courier">In Common Lisp:</font></div><div><font face="Courier"><br></font></div><div><font face="Courier">(defun d ()</font></div><div><font face="Courier"> (throw 'Exception nil))</font></div><div><font face="Courier"><br></font></div><div><font face="Courier">(defun c ()</font></div><div><font face="Courier"> (d)) ; <-- This can be called with llvm “call” but if I JIT this function it will fail! I need to use “invoke”!</font></div><div><font face="Courier"><br></font></div><div><font face="Courier">(defun b ()</font></div><div><font face="Courier"> (c)) ; <-- This can be called with llvm "call"</font></div><div><font face="Courier"><br></font></div><div><font face="Courier">(defun a ()</font></div><div><font face="Courier"> (catch 'exception</font></div><div><font face="Courier"> (b))) ; <-- This needs to called with llvm “invoke"</font></div></div><div><div><div><font face="Courier"><br></font></div><div><font face="Courier"><br></font></div><div><font face="Courier"><br></font></div><div><div><div>On Apr 11, 2015, at 8:15 PM, Logan Chien <<a href="mailto:tzuhsiang.chien@gmail.com" target="_blank">tzuhsiang.chien@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><div>Hi Christian,<br><br>> I don’t see anything in the Itanium ABI that says I need to call
the function that throws an exception with “invoke” to get exception
handling to work!<br><br></div>AFAICT, it is the design of LLVM IR and its implementation. To catch the exceptions thrown by the callee functions, we should use the invoke instruction along with the landingpad instruction. If you are calling a function with a call instruction, the LLVM backend will simply assumes frame unwinding when the callee throws an exception.<br><br><br>FYI, according to LLVM reference manual, an <a href="http://llvm.org/docs/LangRef.html#invoke-instruction" target="_blank">invoke-instruction</a> has following semantics:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><p>The ‘<tt>invoke</tt>‘ instruction causes control to transfer to a specified
function, with the possibility of control flow transfer to either the
‘<tt>normal</tt>‘ label or the ‘<tt>exception</tt>‘ label. If the callee function
returns with the “<tt>ret</tt>” instruction, control flow will return to the
“normal” label. If the callee (or any indirect callees) returns via the
“<a href="http://llvm.org/docs/LangRef.html#i-resume" target="_blank"><em>resume</em></a>” instruction or other exception handling
mechanism, control is interrupted and continued at the dynamically
nearest “exception” label.</p></blockquote><div>OTOH, here's the description for <a href="http://llvm.org/docs/LangRef.html#call-instruction" target="_blank">call instruction</a>: <br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><p>The ‘<tt>call</tt>‘ instruction represents a simple function call.</p></blockquote><div><br>Hope this is helpful.<br><br></div><div>Best regards,<br></div><div>Logan<br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 12, 2015 at 6:33 AM, Christian Schafmeister <span dir="ltr"><<a href="mailto:chris.schaf@verizon.net" target="_blank">chris.schaf@verizon.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div>It appears that I've found a very curious effect where if I JIT a function that throws an exception and I use "call" to call it the throw fails despite there being a "catch" clause on the stack. But if I use “invoke” it works fine!<div><br></div><div> If I call the function (@cc_invoke) that throws a “core::CatchThrow” exception like this:</div><div><pre style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;margin-top:0px;margin-bottom:0px;width:748px;color:rgb(51,51,51);line-height:16px"><div>call void @cc_invoke({ {}*, i64 }* %result-ptr, {}* %3, i64 2, {}* %4, {}* %5, {}* null, {}* null, {}* null)
</div><div>;; Comment out the next two lines and
</div><div>; to label %return0 unwind label %landing-pad1
</div><div>;return0:</div><div>ret void
</div><div>
</div><div>landing-pad1: ; No predecessors!
</div><div> %6 = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0
</div><div> cleanup
</div><div> resume { i8*, i32 } %6
</div><div>}</div></pre><div><br></div></div><div>It fails with: libc++abi.dylib: terminating with uncaught exception of type core::CatchThrow</div><div><br></div><div>If instead I convert the “call” into an “invoke” and hook in a dummy landing-pad like this:</div><div><br></div><div><pre style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;margin-top:0px;margin-bottom:0px;width:748px;color:rgb(51,51,51);line-height:16px"><div>invoke void @cc_invoke({ {}*, i64 }* %result-ptr, {}* %3, i64 2, {}* %4, {}* %5, {}* null, {}* null, {}* null)
</div><div> to label %return0 unwind label %landing-pad1
</div><div>return0:
</div><div> ret void
</div><div>
</div><div>landing-pad1: ; No predecessors!
</div><div> %6 = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0
</div><div> cleanup
</div><div> resume { i8*, i32 } %6
</div><div>}</div></pre><div><br></div><div>The CatchThrow exception is caught and everything works fine! I don’t need to call the caller or any outer function with “invoke” except for in the function that has the landing pad that recognizes core::CatchThrow.</div><div><br></div><div>I don’t see anything in the Itanium ABI that says I need to call the function that throws an exception with “invoke” to get exception handling to work!</div><div><br></div><div>Does anyone have any ideas what I might be doing wrong?</div><div><br></div><div><br></div><br></div><div><div><br></div><div><br></div><div><br></div><div><br><div><div>On Apr 9, 2015, at 6:59 PM, Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">Hi Christian,<div><br></div><div>Andy's already covered the major points, but you could consider filing a bug at <a href="http://llvm.org/bugs" target="_blank">http://llvm.org/bugs</a> too, especially if you've got a small test-case that demonstrates the issue. Exception handling hasn't been a priority in the past, but as more people adopt LLVM's JIT APIs I suspect it will get more attention, and bug reports will help us figure out what needs doing. </div><div><br></div><div>Cheers,</div><div>Lang.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 9, 2015 at 11:43 AM, Kaylor, Andrew <span dir="ltr"><<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi Christian,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I suspect that at least some of the details depend on what platform you’re working on. I believe that MCJIT attempts to register eh frame information for either
MachO or ELF objects (though for some ELF platforms nothing actually happens). What happens to it after that is a darker area, at least for me.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Apparently there was a GDB command that did just what you want -- “info catch” -- but I had never used it and it has been removed. It’s too bad because it
sounds like a nice feature. It was supposed to dump a list of catch handlers for whatever frame you’re looking at. I suspect, however, that it would have just confirmed that your catch handler isn’t properly hooked up without being helpful in figuring out
why.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">You could try debugging the RuntimeDyld code that registers eh frames and see if that looks right. RuntimeDyld::registerEHFrames() might be a helpful starting
point.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">-Andy<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank">llvmdev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank">llvmdev-bounces@cs.uiuc.edu</a>]
<b>On Behalf Of </b>Christian Schafmeister<br>
<b>Sent:</b> Wednesday, April 08, 2015 10:09 PM<br>
<b>To:</b> LLVM Developers Mailing List<br>
<b>Subject:</b> [LLVMdev] Looking for advice on how to debug a problem with C++ style exception handling code that my compiler generates.<u></u><u></u></span></p>
</div>
</div><div><p class="MsoNormal"><u></u> <u></u></p>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">Hi,<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">I’m looking for advice on how to debug a problem with my exception handling code. <u></u><u></u></p>
</div>
<div><p class="MsoNormal">I’m asking a specific question here - but general advice on how to debug something like this would be greatly appreciated.<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div><p class="MsoNormal">Is there any way to get a list of landing pad clauses that are active at a particular point in a program?<br>
I'd like to get something like a backtrace but listing all active landing pad clauses. The typeids of the C++ types <br>
I'm trying to debug a problem where an exception that I'm throwing is not being caught. <u></u><u></u></p>
<div><p class="MsoNormal">I'm generating JITed code with LLVM and landing pads and I've got shared libraries - lots of things going on that could potentially be going wrong.<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">A list of the pointer values like @_ZTIN4core9DynamicGoE is what I’m looking for. Then I could compare that to the typeids that I know should be in that list.<u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div><p class="MsoNormal"><span style="font-family:Courier">"(TRY-0).landing-pad": ; preds = %"(TRY-0).normal-dest14", %"(TRY-0).tagbody-B-1", %"(TRY-0).normal-dest10", %"(TRY-0).normal-dest9", %"(TRY-0).normal-dest8", %"(TRY-0).normal-dest",
%"(TRY-0).tagbody-#:G1621-0"</span><u></u><u></u></p>
</div>
<div><p class="MsoNormal"><span style="font-family:Courier"> %14 = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0</span><u></u><u></u></p>
</div>
<div><p class="MsoNormal"><span style="font-family:Courier"> catch i8* @_ZTIN4core9DynamicGoE</span><u></u><u></u></p>
</div>
<div><p class="MsoNormal"><span style="font-family:Courier"> catch i8* @_ZTIN4core10ReturnFromE, !dbg !26</span><u></u><u></u></p>
</div>
<div><p class="MsoNormal"><span style="font-family:Courier"> %15 = extractvalue { i8*, i32 } %14, 0, !dbg !26</span><u></u><u></u></p>
</div>
<div><p class="MsoNormal"><span style="font-family:Courier"> %16 = extractvalue { i8*, i32 } %14, 1, !dbg !26</span><u></u><u></u></p>
</div>
<div><p class="MsoNormal"><span style="font-family:Courier"> %17 = call i32 @llvm.eh.typeid.for(i8* @_ZTIN4core9DynamicGoE), !dbg !26</span><u></u><u></u></p>
</div>
<div><p class="MsoNormal"><span style="font-family:Courier"> %18 = icmp eq i32 %16, %17, !dbg !26</span><u></u><u></u></p>
</div>
<div><p class="MsoNormal"><span style="font-family:Courier"> br i1 %18, label %"(TRY-0).handler-block14470", label %"(TRY-0).dispatch-header19", !dbg !26</span><u></u><u></u></p>
</div>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">I’m getting this error when I throw a core::Unwind exception and I’m certain that there is a landing pad with that clause.</span><u></u><u></u></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div><p class="MsoNormal"><span style="font-family:Courier">libc++abi.dylib: terminating with uncaught exception of type core::Unwind</span><u></u><u></u></p>
</div>
<div><p class="MsoNormal"><span style="font-family:Courier">../../src/gctools/<a href="http://memorymanagement.cc/" target="_blank">memoryManagement.cc</a>:75 Trapped SIGABRT - starting debugger</span><u></u><u></u></p>
</div>
<div><p class="MsoNormal"><span style="font-family:Courier">ABORT was called!!!!!!!!!!!!</span><u></u><u></u></p>
</div>
<div><p class="MsoNormal"><span style="font-family:Courier"><u></u> <u></u></span></p>
</div>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal">I’ve written a Common Lisp compiler that uses LLVM as the backend and it interoperates with C++ code and I use C++ exception handling for non-local exits.<u></u><u></u></p>
</div>
</div></div>
</div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></blockquote></div><br></div></div></div></div></blockquote></div><br></div>