Displaying 4 results from an estimated 4 matches for "v_callinst".
2007 Jul 02
2
[LLVMdev] API design
> > I'd like to get the extra checks working so that they can help find our
> > more subtle bugs. Any idea what we should do here?
>
> I don't really have a good idea, but I also don't want to significantly
> uglify the sourcebase...
#define V_CALLINST(V, Args) new CallInst(V, Args.size() == 0 ? NULL :
&Args[0], Args.size())
:p
-Keith
2007 Jul 03
0
[LLVMdev] API design
...gt; I'd like to get the extra checks working so that they can help find our
> > > more subtle bugs. Any idea what we should do here?
> >
> > I don't really have a good idea, but I also don't want to significantly
> > uglify the sourcebase...
>
> #define V_CALLINST(V, Args) new CallInst(V, Args.size() == 0 ? NULL :
> &Args[0], Args.size())
I'd actually prefer a new constructor here. One that doesn't take any
Args at all. API wise its a little more clear what's going on, so you'd
have:
if (Args.size())
new CallInst(V, &Args[0], A...
2007 Jul 02
0
[LLVMdev] API design
On Sun, 1 Jul 2007, Nick Lewycky wrote:
> I've been running LLVM with _GLIBCXX_DEBUG (extra checks) turned on to
> see what would happen, and it's been a complete disaster.
>
> The major problem is the use of this API:
>
> new CallInst(V, &Args[0], Args.size());
>
> repeated throughout LLVM. When Args is empty, Args[0] is invalid, even
> if the next
2007 Jul 02
6
[LLVMdev] API design
Hi,
I've been running LLVM with _GLIBCXX_DEBUG (extra checks) turned on to
see what would happen, and it's been a complete disaster.
The major problem is the use of this API:
new CallInst(V, &Args[0], Args.size());
repeated throughout LLVM. When Args is empty, Args[0] is invalid, even
if the next operation is taking the address. Trying to fix it
illustrates the depth of the