On Tue, Feb 15, 2011 at 05:22:02PM -0500, Jesse M Draper wrote:
> I have a small patch to bin/cilly that helps me when I'm debugging Cil
> code in emacs with ocamldebug.
Applied in svn r12139.
Thanks,
--
Gabriel
--
The
Thanks!
On 15 February 2011 23:47, Gabriel Kerneis wrote:
> On Tue, Feb 15, 2011 at 09:27:51PM -0800, Jonathan Kotker wrote:
> > Thanks for the information! :) I guess I didn't understand the C
> > compilation toolflow well enough: just to clarify then, just because you
> > mention to include
On Tue, Feb 15, 2011 at 09:27:51PM -0800, Jonathan Kotker wrote:
> Thanks for the information! :) I guess I didn't understand the C
> compilation toolflow well enough: just to clarify then, just because you
> mention to include a file called "x.h", GCC and CIL will not look for a file
> called "x
Hi Zakkak.
Thanks for the information! :) I guess I didn't understand the C
compilation toolflow well enough: just to clarify then, just because you
mention to include a file called "x.h", GCC and CIL will not look for a file
called "x.c"?
Best,
Jon.
On 15 February 2011 17:28, Zakkak Foivos w
Hi,
As far as i know, you will have to use --merge and give foo.c to cilly
along with the file to analyze. There is no way cilly can find the file
containing the function definition of foo, as it can be defined in any
file or even implemented in a library.
Zakkak Foivos
On 02/16/2011 01:48 AM
Hello.
I was wondering how to get CIL to include functions from user-defined header
files. For instance, I have the header file "foo.h", which contains
int bar(void);
There is another file "foo.c" that contains the definition of the "bar"
function. Now, let us say that the file we are going to
I have a small patch to bin/cilly that helps me when I'm debugging Cil code in
emacs with
ocamldebug. I am usually invoking my-camldebug from a directory where my source
C files are. I can
easily set breakpoints in my own Cil code, but moving up the call chain is
thwarted by the
debugger's in
On Tue, Feb 15, 2011 at 10:10:46AM -0500, Elnatan Reisner wrote:
> I haven't thought hard about this, but it looks to me like the key
> in the cases where result is not used is just that the cast is not
> inserted, so I think you should still used the 'rolled' type---that
> is, the input [nt], rath
On Feb 15, 2011, at 7:40 AM, Gabriel Kerneis wrote:
> On Thu, Jan 20, 2011 at 10:57:22PM -0500, Elnatan Reisner wrote:
>> The attached patch keeps the typedefed type in casts, rather than
>> unrolling to the underlying type.
>
> Applied in svn r12134.
>
> Note that in some cases in the pattern-mat
On Thu, Feb 03, 2011 at 02:13:12PM -0500, Jesse M Draper wrote:
> My patch to src/frontc/cabs2cil.ml checks for
> "__builtin_object_size" and, following the pattern in
> "__builtin_constant_p", drops the side effects.
I am not convinced this patch is correct (although current behaviour is
obviousl
On Fri, Feb 04, 2011 at 12:24:50PM -0500, Jesse M Draper wrote:
> The error occurs in d_const, which assumes that only long long
> integers are 64 bits and therefore truncates long integers to 32
> bits. Since the argument of -1 is handled correctly in both
> programs, I am assuming that the error
On Tue, Jan 25, 2011 at 04:55:02PM -0600, Piramanayagam Arumuga Nainar wrote:
> This is a patch that adds a new flag considerVariableAddrOfAsDef to
> the Use-Def Analysis. It is similar to considerVariableAddrOfAsUse.
> If enabled, taking the address of a variable will be considered as a
> definit
On Thu, Jan 20, 2011 at 10:57:22PM -0500, Elnatan Reisner wrote:
> The attached patch keeps the typedefed type in casts, rather than
> unrolling to the underlying type.
Applied in svn r12134.
Note that in some cases in the pattern-matching (eg. TArray), the
variable [result] in not used, and the
On Thu, Jan 20, 2011 at 04:41:26PM -0500, Elnatan Reisner wrote:
> A '?:' expression, when occurring as a standalone statement, gets
> expanded into an 'if' statement, even if there are no side-effects
> in either branch. This patch fixes that by simply eliminating the
> statement altogether, or ke
14 matches
Mail list logo