search for: onstacksize

Displaying 4 results from an estimated 4 matches for "onstacksize".

2013 Jul 23
2
[LLVMdev] [RFC] Add warning capabilities in LLVM.
...ers point (sorry, I hate to play Telephone here - but hope to help clarify some positions... apologies if this just further obfuscates/confuses). I believe the idea is some kind of generic callback type with a bunch of no-op-default callbacks, override the ones your frontend cares about ("void onStackSize(size_t bytes)", etc...). Yes, we could come up with a system that doesn't require adding a new function call for every data that needs to be provided. Does it seem likely we'll have so many of these that we'll really want/need that? > I think we should still provide an informa...
2013 Jul 23
0
[LLVMdev] [RFC] Add warning capabilities in LLVM.
...hate to play > Telephone here - but hope to help clarify some positions... apologies > if this just further obfuscates/confuses). I believe the idea is some > kind of generic callback type with a bunch of no-op-default callbacks, > override the ones your frontend cares about ("void onStackSize(size_t > bytes)", etc...). I see. > > Yes, we could come up with a system that doesn't require adding a new > function call for every data that needs to be provided. Does it seem > likely we'll have so many of these that we'll really want/need that? That’s a good...
2013 Jul 22
0
[LLVMdev] [RFC] Add warning capabilities in LLVM.
Hi, Compared to my previous email, I have added Hal’s idea for formatting the message and pull back some idea from the "querying framework”. Indeed, I propose to add some information in the reporting so that a front-end (more generally a client) can filter the diagnostics or take proper actions. See the details hereafter. On Jul 22, 2013, at 2:25 PM, Chandler Carruth <chandlerc at
2013 Jul 22
5
[LLVMdev] [RFC] Add warning capabilities in LLVM.
On Mon, Jul 22, 2013 at 2:21 PM, Eric Christopher <echristo at gmail.com>wrote: > >> This is pretty much the same as what Quentin proposed (with the > addition of the enum), isn't it? > >> > > > > Pretty close yeah. > > > > Another thought and alternate strategy for dealing with these sorts of > things: > > A much more broad set of