Displaying 4 results from an estimated 4 matches for "assertvhs".
Did you mean:
assertvh
2014 Jan 04
2
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
On Jan 3, 2014, at 2:19 PM, Chandler Carruth <chandlerc at google.com> wrote:
>> While having different components of LLVM and consumers of LLVM able to intermix NDEBUG and !NDEBUG built code freely without ABI issues is nice-to-have in my book, the functionality provided by AssertingVH is significantly more nice-to-have, and I don't see any easy ways to contain or limit the
2014 Jan 03
2
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
On Jan 3, 2014, at 1:55 PM, Chandler Carruth <chandlerc at google.com> wrote:
> >
> > The key thing then is to make sure that it's safe to enable the
> > assertions in the headers if an application is built with !NDEBUG and
> > linked against an NDEBUG version of LLVM.
>
> Sounds great. I'm pretty confident that there will be no problems - in practice
2010 Nov 08
1
[LLVMdev] how to delete an invalidated call graph
Hello,
I am working on the the "Global Variable Optimizer" pass. I'd like to
modify this pass to be more aggressive. Therefore I need the call
graph. The call graph contains AssertVHs of all functions. If the
"Global Variable Optimizer" pass identifies a function to be delete
able it will be deleted immediately by this pass. The call graph is
not destroyed before. That's why deleting a function leads to an
assert in Value.cpp: "While deleting: i32 (...)* %asse...
2013 Nov 12
3
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
On Nov 11, 2013, at 12:09 PM, Alp Toker <alp at nuanti.com> wrote:
>> Even when you have a !NDEBUG build, the platform assert() is pretty
>> crummy on Windows and generates, at best a UTF-16 dump, or sometimes
>> just pops up a dialog. WebKit and other projects take the same approach
>> and define their own assertion macros to deal with this portably.
>>