[CIL users] [ cil-Bugs-3532983 ] Handling of array initialization is incorrect
Bugs item #3532983, was opened at 2012-06-07 14:07
Message generated for change (Comment added) made by kerneis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3532983&group_id=138953
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: CIL core (parser, visitor, etc)
Group: Bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ed Schwartz (edmcman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Handling of array initialization is incorrect
Initial Comment:
Consider an array, int x[5] = {0, };
In 6.7.8, paragraph 21 of the C99 standard:
If there are fewer initializers in a brace-enclosed list than there are
elements or members
of an aggregate, or fewer characters in a string literal used to initialize an
array of known
size than there are elements in the array, the remainder of the aggregate shall
be
initialized implicitly the same as objects that have static storage duration.
In other words, when in doubt, initialize to zero.
CIL does this, but only for up to 16 elements. If it has to put an implied
zero for more than 16 elements, it does not put any implied zeros. This is
wrong, and has lead to incorrect behavior on real code. Specifically, in
card_of_complement from tr.c, in coreutils:
bool in_set[N_CHARS] = { 0, };
where N_CHARS = 256.
There seem to be a few ways of solving this problem:
* Remove the 16 element limit. This could add a lot of statements.
* Allow local variables to use initializers. Global variables are allowed
initializers, but not local ones... is there any reason for this?
* Add a loop to initialize the array
I don't mind implementing one of these, but I want to make sure it's something
worth including in the CIL codebase. I prefer the third option.
--
>Comment By: Gabriel Kerneis (kerneis)
Date: 2012-06-11 22:24
Message:
In fact, your patch is incorrect is several places:
> The loop is currently only added when there are more than 16 implied
initializers
no it's not (and that's one of the reasons why it breaks the test suite),
But anyway I'll remove these 16-initializers trick.
> BinOp(Ge, Lval ctrlval, Const(CInt64(ni, IUInt, None)), uintType)
Binop(Ge, …) requires intType, not uintType.
> castTo iet (typeOfLval lv) (Const(CInt64(0L, IUInt, None)))
This one is the real problem. IIUC, you copy/pasted it from the SingleInit
case, but it does not work. You could have an array of any type (bt), the
cast is non-sensical and you have no guarantee that a direct init is
possibe (it could be an array of struct containing an array, etc.). I think
the solution is to call assignInit recursively with makeZeroInit bt, but I
have to test it to be sure.
--
Comment By: Ed Schwartz (edmcman)
Date: 2012-06-11 06:53
Message:
Hi Gabriel,
The loop is currently only added when there are more than 16 implied
initializers. I also don't like magic numbers, but it could simplify
program analysis to have the unrolled initializers outside of the loop when
there are only a few of them, so I see a case for both sides.
I do not feel strongly either way. Feel free to amend the patch in
whatever way you think is best.
Thanks,
Ed
--
Comment By: Gabriel Kerneis (kerneis)
Date: 2012-06-11 00:22
Message:
Looks good to me. However, is there any reason to keep the first 16
initializers in collectInitializers since we add the loop in every case? I
think we should get rid of it but I might be missing something. Or use a
loop only for longer arrays, but I prefer avoiding "magic numbers". If you
agree, I'll amend the patch, test it and apply it.
--
Comment By: Ed Schwartz (edmcman)
Date: 2012-06-10 18:06
Message:
I attached a patch for this. Let me know if you have any comments..
--
Comment By: Ed Schwartz (edmcman)
Date: 2012-06-08 07:48
Message:
Calling memset is a good idea.
VC++ does have intrinsics:
http://msdn.microsoft.com/en-us/library/26td21ds(v=VS.80).aspx
But, there are a few problems that I can see:
* They can only be enabled at the file level; so if someone was using
memset and expected it to be a function call, that could be a problem if we
needed to use the intrinsic.
* To use the intrinsics, one needs to include a header file which seems to
cause problems:
https://www.google.com/webhp?sourceid=chrome-instant&ie=UTF-8&ion=1#hl=en&sclient=psy-ab&q=intrin.h%20windows.h%20conflict&oq=&aq=&aqi=&aql=&gs_l=&pbx=1&fp=48739054e748cc81&ion=1&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.,cf.osb&biw=1198&bih=1495
* In my tests, the memset intrinsic just calls
[CIL users] [ cil-Bugs-3534428 ] newTempVar called outside a function
Bugs item #3534428, was opened at 2012-06-11 13:28 Message generated for change (Comment added) made by kerneis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3534428&group_id=138953 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Ed Schwartz (edmcman) Assigned to: Nobody/Anonymous (nobody) Summary: newTempVar called outside a function Initial Comment: One of the gnulib tests used in coreutils triggers a CIL bug: CC test-stdbool.o gcc -D_GNUCC -E -MT test-stdbool.o -MD -MP -MF .deps/test-stdbool.Tpo -I. -I../lib -DIN_COREUTILS_GNULIB_TESTS=1 -I. -I. -I.. -I./.. -I../lib -I./../lib -g -O2 -DCIL=1 test-stdbool.c -o ./test-stdbool.i /home/ed/f11/decompiler-transformer/vendor/cil/1.4.0/obj/x86_LINUX/cilly.asm.exe --out ./test-stdbool.cil.c ./test-stdbool.i test-stdbool.c:63: Bug: newTempVar called outside a function test-stdbool.c:63: Error: doPureExp: not pure Fatal error: exception Errormsg.Error make[3]: *** [test-stdbool.o] Error 2 I am uploading test-stdbool.i -- >Comment By: Gabriel Kerneis (kerneis) Date: 2012-06-12 01:15 Message: This is because CIL tries to fold the ternary operator ?: but is unable to fold floats. I added your file to the test suite. A work-around is to use the feature-question branch: http://github.com/kerneis/cil/commits/feature-question I have just rebased it against develop, and your test works in that case (with the --use-logical-operators flag). I used to be reluctant to merge it because it would change the CIL AST, breaking existing code; I might change my mind if people have a strong need for it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3534428&group_id=138953 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ CIL-users mailing list CIL-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cil-users
[CIL users] [ cil-Bugs-3532983 ] Handling of array initialization is incorrect
Bugs item #3532983, was opened at 2012-06-07 14:07
Message generated for change (Comment added) made by kerneis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3532983&group_id=138953
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: CIL core (parser, visitor, etc)
Group: Bug
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Ed Schwartz (edmcman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Handling of array initialization is incorrect
Initial Comment:
Consider an array, int x[5] = {0, };
In 6.7.8, paragraph 21 of the C99 standard:
If there are fewer initializers in a brace-enclosed list than there are
elements or members
of an aggregate, or fewer characters in a string literal used to initialize an
array of known
size than there are elements in the array, the remainder of the aggregate shall
be
initialized implicitly the same as objects that have static storage duration.
In other words, when in doubt, initialize to zero.
CIL does this, but only for up to 16 elements. If it has to put an implied
zero for more than 16 elements, it does not put any implied zeros. This is
wrong, and has lead to incorrect behavior on real code. Specifically, in
card_of_complement from tr.c, in coreutils:
bool in_set[N_CHARS] = { 0, };
where N_CHARS = 256.
There seem to be a few ways of solving this problem:
* Remove the 16 element limit. This could add a lot of statements.
* Allow local variables to use initializers. Global variables are allowed
initializers, but not local ones... is there any reason for this?
* Add a loop to initialize the array
I don't mind implementing one of these, but I want to make sure it's something
worth including in the CIL codebase. I prefer the third option.
--
>Comment By: Gabriel Kerneis (kerneis)
Date: 2012-06-12 02:32
Message:
Committed an amended version of your patch with recursive calls to
assignInit.
--
Comment By: Gabriel Kerneis (kerneis)
Date: 2012-06-11 22:24
Message:
In fact, your patch is incorrect is several places:
> The loop is currently only added when there are more than 16 implied
initializers
no it's not (and that's one of the reasons why it breaks the test suite),
But anyway I'll remove these 16-initializers trick.
> BinOp(Ge, Lval ctrlval, Const(CInt64(ni, IUInt, None)), uintType)
Binop(Ge, …) requires intType, not uintType.
> castTo iet (typeOfLval lv) (Const(CInt64(0L, IUInt, None)))
This one is the real problem. IIUC, you copy/pasted it from the SingleInit
case, but it does not work. You could have an array of any type (bt), the
cast is non-sensical and you have no guarantee that a direct init is
possibe (it could be an array of struct containing an array, etc.). I think
the solution is to call assignInit recursively with makeZeroInit bt, but I
have to test it to be sure.
--
Comment By: Ed Schwartz (edmcman)
Date: 2012-06-11 06:53
Message:
Hi Gabriel,
The loop is currently only added when there are more than 16 implied
initializers. I also don't like magic numbers, but it could simplify
program analysis to have the unrolled initializers outside of the loop when
there are only a few of them, so I see a case for both sides.
I do not feel strongly either way. Feel free to amend the patch in
whatever way you think is best.
Thanks,
Ed
--
Comment By: Gabriel Kerneis (kerneis)
Date: 2012-06-11 00:22
Message:
Looks good to me. However, is there any reason to keep the first 16
initializers in collectInitializers since we add the loop in every case? I
think we should get rid of it but I might be missing something. Or use a
loop only for longer arrays, but I prefer avoiding "magic numbers". If you
agree, I'll amend the patch, test it and apply it.
--
Comment By: Ed Schwartz (edmcman)
Date: 2012-06-10 18:06
Message:
I attached a patch for this. Let me know if you have any comments..
--
Comment By: Ed Schwartz (edmcman)
Date: 2012-06-08 07:48
Message:
Calling memset is a good idea.
VC++ does have intrinsics:
http://msdn.microsoft.com/en-us/library/26td21ds(v=VS.80).aspx
But, there are a few problems that I can see:
* They can only be enabled at the file level; so if someone was using
memset and expected it to be a function call, that could be a problem if we
needed to use the intrinsic.
* To use the intrinsics, one needs to include a header file which seems to
cause problems:
https://www.google.com/webhp?sourceid=chrome-instant&ie=
[CIL users] [ cil-Bugs-3534428 ] newTempVar called outside a function
Bugs item #3534428, was opened at 2012-06-11 13:28 Message generated for change (Comment added) made by kerneis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3534428&group_id=138953 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Ed Schwartz (edmcman) Assigned to: Nobody/Anonymous (nobody) Summary: newTempVar called outside a function Initial Comment: One of the gnulib tests used in coreutils triggers a CIL bug: CC test-stdbool.o gcc -D_GNUCC -E -MT test-stdbool.o -MD -MP -MF .deps/test-stdbool.Tpo -I. -I../lib -DIN_COREUTILS_GNULIB_TESTS=1 -I. -I. -I.. -I./.. -I../lib -I./../lib -g -O2 -DCIL=1 test-stdbool.c -o ./test-stdbool.i /home/ed/f11/decompiler-transformer/vendor/cil/1.4.0/obj/x86_LINUX/cilly.asm.exe --out ./test-stdbool.cil.c ./test-stdbool.i test-stdbool.c:63: Bug: newTempVar called outside a function test-stdbool.c:63: Error: doPureExp: not pure Fatal error: exception Errormsg.Error make[3]: *** [test-stdbool.o] Error 2 I am uploading test-stdbool.i -- >Comment By: Gabriel Kerneis (kerneis) Date: 2012-06-14 03:34 Message: I merged the Question feature into develop. -- Comment By: Gabriel Kerneis (kerneis) Date: 2012-06-12 01:15 Message: This is because CIL tries to fold the ternary operator ?: but is unable to fold floats. I added your file to the test suite. A work-around is to use the feature-question branch: http://github.com/kerneis/cil/commits/feature-question I have just rebased it against develop, and your test works in that case (with the --use-logical-operators flag). I used to be reluctant to merge it because it would change the CIL AST, breaking existing code; I might change my mind if people have a strong need for it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3534428&group_id=138953 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ CIL-users mailing list CIL-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cil-users
[CIL users] [ cil-Bugs-3538514 ] Pointer difference operations have the wrong type.
Bugs item #3538514, was opened at 2012-06-27 14:38
Message generated for change (Tracker Item Submitted) made by jimgrundy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3538514&group_id=138953
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: CIL core (parser, visitor, etc)
Group: Bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Grundy (jimgrundy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pointer difference operations have the wrong type.
Initial Comment:
Pointer difference operations should have some type that corresponds to
ptrdiff_t, but the cabs2cil transformation creates them with type "int". The
"int" type is often not as big as ptrdiff_t. The result of this that sometimes
the types of the arguments of binary operators do not match (though CIL thinks
they do).
Consider the following program:
int main()
{
int i;
int *p = &i;
int *q = &p;
short s = 1;
long d = (p - q) + s;
return 0;
}
CIL will translate the statement "d = (p - q) + s;" to "d = (long)((p - q) +
(int)s);". It should have created "d = (long)((p - q) + (ptrdiff_t)s);".
A patch to fix the bug is attached.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3538514&group_id=138953
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
CIL-users mailing list
CIL-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cil-users
[CIL users] [ cil-Bugs-3538514 ] Pointer difference operations have the wrong type.
Bugs item #3538514, was opened at 2012-06-27 14:38
Message generated for change (Comment added) made by kerneis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3538514&group_id=138953
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: CIL core (parser, visitor, etc)
Group: Bug
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Jim Grundy (jimgrundy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pointer difference operations have the wrong type.
Initial Comment:
Pointer difference operations should have some type that corresponds to
ptrdiff_t, but the cabs2cil transformation creates them with type "int". The
"int" type is often not as big as ptrdiff_t. The result of this that sometimes
the types of the arguments of binary operators do not match (though CIL thinks
they do).
Consider the following program:
int main()
{
int i;
int *p = &i;
int *q = &p;
short s = 1;
long d = (p - q) + s;
return 0;
}
CIL will translate the statement "d = (p - q) + s;" to "d = (long)((p - q) +
(int)s);". It should have created "d = (long)((p - q) + (ptrdiff_t)s);".
A patch to fix the bug is attached.
--
>Comment By: Gabriel Kerneis (kerneis)
Date: 2012-07-03 22:36
Message:
Applied, thanks.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3538514&group_id=138953
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
CIL-users mailing list
CIL-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cil-users
[CIL users] [ cil-Bugs-3544467 ] Disparity between CIL and GCC in struct/union merging
Bugs item #3544467, was opened at 2012-07-15 17:08
Message generated for change (Tracker Item Submitted) made by
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3544467&group_id=138953
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: CIL core (parser, visitor, etc)
Group: Bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Cody Schuffelen ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Disparity between CIL and GCC in struct/union merging
Initial Comment:
In the attached two files (file1.c and file2.c, combined into one file),
"struct myStruct" is defined two different ways, each holding a slightly
different anonymous union:
//file1.c
union {
long long int i;
int* p;
char c;
};
//file2.c
union {
long long int i;
double f;
};
Using gcc and ar, I can compile these two files together into a single object
file without errors.
gcc -c file1.c
gcc -c file2.c
ar cruv out.a file1.o file2.o
However, using cilly and attempting to merge these two with the following
commands:
cilly --merge -c file1.c
cilly --merge -c file2.c
cilly --merge --mode=AR cruv out.a file1.o file2.o
I get the following error from CIL:
:-1: Error: Incompatible declaration for build (from file2.o(1)).
Previous was at file1.c:13 (from file1.o (0))
Failed assumption that struct myStruct and struct myStruct are
isomorphic (different number of fields in __anonunionmissing_field_name_24
and __anonunionmissing_field_name_24: 3 != 2.)
struct myStruct {
int a ;
union __anonunionmissing_field_name_24 __annonCompField1 ;
};
struct myStruct {
int a ;
union __anonunionmissing_field_name_24 __annonCompField1 ;
};
Final merging phase (0): file1.o
Final merging phase (1): file2.o
file2.c:12: Warning: The name build is used for two distinct globals
Error: There were errors during merging
This is a trivial example of the error I'm getting in a larger project that I
am trying to merge together. I am using CIL 1.5.1, downloaded earlier today
from SourceForge.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3544467&group_id=138953
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
CIL-users mailing list
CIL-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cil-users
[CIL users] [ cil-Bugs-3586613 ] Cil Visitor vs Cabs2cil Visitor
Bugs item #3586613, was opened at 2012-11-12 22:13 Message generated for change (Tracker Item Submitted) made by theanh2504 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3586613&group_id=138953 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: TheAnh Do (theanh2504) Assigned to: Nobody/Anonymous (nobody) Summary: Cil Visitor vs Cabs2cil Visitor Initial Comment: Dear Cil users, I am currently investigating a research tool which is developed based on Cil. I have found that the tool mainly use Cabs2cil visitor class instead of Cil visitor which I normally see. Could anyone please tell me the difference between using Cil visitor and Cabs2cil visitor? And often in which situations we should or should not use Cabs2cil visitor. Thanks very much. TheAnh Do -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3586613&group_id=138953 -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ CIL-users mailing list CIL-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cil-users
[CIL users] [ cil-Bugs-3604915 ] Legal, but large, static arrays can fail.
Bugs item #3604915, was opened at 2013-02-15 13:29 Message generated for change (Tracker Item Submitted) made by jim_grundy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3604915&group_id=138953 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: CIL core (parser, visitor, etc) Group: Bug Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Grundy (jim_grundy) Assigned to: Nobody/Anonymous (nobody) Summary: Legal, but large, static arrays can fail. Initial Comment: We've encounterd embedded programs that carve out large static arrays ... and they compile and run correctly, but CIL can't process them because the array's are too big. In particular, CIL appears to use an OCaml int for an array size, but since OCaml int's are 1) signed 2) 1-bit shorter than machine ints to facilitate fast garbage collection; it is possible - and we do - have arrays with a size that is bigger than can be represented with an OCaml int. Natrually this is a problem in practice only on 32-bit builds, but since all the pre-combiled Windows OCaml builds are 32-bit the problem occurs. I believe this to be the cause because if I set the size to be one byte smaller than the largest 2s complement number representable in 31 bits it works. Now, "morally", CIL should be able to process any C file that the compiler can process - but on a 32-bit machine this does break down here. I expect the right thing to do would be to modify CIL to use Nativeint library for storying array sizes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3604915&group_id=138953 -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ CIL-users mailing list CIL-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cil-users
[CIL users] [ cil-Bugs-3604915 ] Legal, but large, static arrays can fail.
Bugs item #3604915, was opened at 2013-02-15 13:29 Message generated for change (Comment added) made by kerneis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3604915&group_id=138953 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: CIL core (parser, visitor, etc) Group: Bug Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Grundy (jim_grundy) Assigned to: Nobody/Anonymous (nobody) Summary: Legal, but large, static arrays can fail. Initial Comment: We've encounterd embedded programs that carve out large static arrays ... and they compile and run correctly, but CIL can't process them because the array's are too big. In particular, CIL appears to use an OCaml int for an array size, but since OCaml int's are 1) signed 2) 1-bit shorter than machine ints to facilitate fast garbage collection; it is possible - and we do - have arrays with a size that is bigger than can be represented with an OCaml int. Natrually this is a problem in practice only on 32-bit builds, but since all the pre-combiled Windows OCaml builds are 32-bit the problem occurs. I believe this to be the cause because if I set the size to be one byte smaller than the largest 2s complement number representable in 31 bits it works. Now, "morally", CIL should be able to process any C file that the compiler can process - but on a 32-bit machine this does break down here. I expect the right thing to do would be to modify CIL to use Nativeint library for storying array sizes. -- >Comment By: Gabriel Kerneis (kerneis) Date: 2013-02-15 13:49 Message: Since CIL 1.7 (I think), length of arrays is stored as a CInt64 when it is known explicitely. However, Cil.lenOfArray converts it to int (Cil.bitsSizeOf also has a similar behaviour, see bug 1641570). What are you trying to do and how does CIL fail exactly when you process these programs? Could you post a (script to generate) an example program? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3604915&group_id=138953 -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ CIL-users mailing list CIL-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cil-users
[CIL users] [ cil-Bugs-3604915 ] Legal, but large, static arrays can fail.
Bugs item #3604915, was opened at 2013-02-15 13:29 Message generated for change (Comment added) made by kerneis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3604915&group_id=138953 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: CIL core (parser, visitor, etc) Group: Bug Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Grundy (jim_grundy) Assigned to: Nobody/Anonymous (nobody) Summary: Legal, but large, static arrays can fail. Initial Comment: We've encounterd embedded programs that carve out large static arrays ... and they compile and run correctly, but CIL can't process them because the array's are too big. In particular, CIL appears to use an OCaml int for an array size, but since OCaml int's are 1) signed 2) 1-bit shorter than machine ints to facilitate fast garbage collection; it is possible - and we do - have arrays with a size that is bigger than can be represented with an OCaml int. Natrually this is a problem in practice only on 32-bit builds, but since all the pre-combiled Windows OCaml builds are 32-bit the problem occurs. I believe this to be the cause because if I set the size to be one byte smaller than the largest 2s complement number representable in 31 bits it works. Now, "morally", CIL should be able to process any C file that the compiler can process - but on a 32-bit machine this does break down here. I expect the right thing to do would be to modify CIL to use Nativeint library for storying array sizes. -- >Comment By: Gabriel Kerneis (kerneis) Date: 2013-02-15 14:00 Message: I meant CIL 1.4, 1.7 does not even exist... -- Comment By: Gabriel Kerneis (kerneis) Date: 2013-02-15 13:49 Message: Since CIL 1.7 (I think), length of arrays is stored as a CInt64 when it is known explicitely. However, Cil.lenOfArray converts it to int (Cil.bitsSizeOf also has a similar behaviour, see bug 1641570). What are you trying to do and how does CIL fail exactly when you process these programs? Could you post a (script to generate) an example program? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3604915&group_id=138953 -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ CIL-users mailing list CIL-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cil-users
[CIL users] [ cil-Bugs-3604915 ] Legal, but large, static arrays can fail.
Bugs item #3604915, was opened at 2013-02-15 13:29
Message generated for change (Comment added) made by jim_grundy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3604915&group_id=138953
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: CIL core (parser, visitor, etc)
Group: Bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Grundy (jim_grundy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Legal, but large, static arrays can fail.
Initial Comment:
We've encounterd embedded programs that carve out large static arrays ... and
they compile and run correctly, but CIL can't process them because the array's
are too big.
In particular, CIL appears to use an OCaml int for an array size, but since
OCaml int's are 1) signed 2) 1-bit shorter than machine ints to facilitate fast
garbage collection; it is possible - and we do - have arrays with a size that
is bigger than can be represented with an OCaml int.
Natrually this is a problem in practice only on 32-bit builds, but since all
the pre-combiled Windows OCaml builds are 32-bit the problem occurs.
I believe this to be the cause because if I set the size to be one byte smaller
than the largest 2s complement number representable in 31 bits it works.
Now, "morally", CIL should be able to process any C file that the compiler can
process - but on a 32-bit machine this does break down here. I expect the right
thing to do would be to modify CIL to use Nativeint library for storying array
sizes.
--
>Comment By: Jim Grundy (jim_grundy)
Date: 2013-02-15 14:24
Message:
Hi Gabriel
We're doing a source-to-source transform using Cil as a library. The error
we are getting is:
Length of array is too large
Which looks like it comes from frontc/cabs2cil.ml/doType
I'm not sure what's going on here ... but my guess is that it is tryng to
compute the size of the array to record it as an attirbute, but the
atributes use OCaml ints rather than 64-bit ints so it won't fit.
The example program is just this - run with a 32-bit OCaml build on a
64-bit Windows machine.
char big_array[1073741824];
int main () {
return 0;
}
All the best
Jim
--
Comment By: Gabriel Kerneis (kerneis)
Date: 2013-02-15 14:00
Message:
I meant CIL 1.4, 1.7 does not even exist...
--
Comment By: Gabriel Kerneis (kerneis)
Date: 2013-02-15 13:49
Message:
Since CIL 1.7 (I think), length of arrays is stored as a CInt64 when it is
known explicitely. However, Cil.lenOfArray converts it to int
(Cil.bitsSizeOf also has a similar behaviour, see bug 1641570). What are
you trying to do and how does CIL fail exactly when you process these
programs? Could you post a (script to generate) an example program?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3604915&group_id=138953
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
CIL-users mailing list
CIL-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cil-users
[CIL users] [ cil-Bugs-3604915 ] Legal, but large, static arrays can fail.
Bugs item #3604915, was opened at 2013-02-15 13:29
Message generated for change (Comment added) made by kerneis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3604915&group_id=138953
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: CIL core (parser, visitor, etc)
Group: Bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Grundy (jim_grundy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Legal, but large, static arrays can fail.
Initial Comment:
We've encounterd embedded programs that carve out large static arrays ... and
they compile and run correctly, but CIL can't process them because the array's
are too big.
In particular, CIL appears to use an OCaml int for an array size, but since
OCaml int's are 1) signed 2) 1-bit shorter than machine ints to facilitate fast
garbage collection; it is possible - and we do - have arrays with a size that
is bigger than can be represented with an OCaml int.
Natrually this is a problem in practice only on 32-bit builds, but since all
the pre-combiled Windows OCaml builds are 32-bit the problem occurs.
I believe this to be the cause because if I set the size to be one byte smaller
than the largest 2s complement number representable in 31 bits it works.
Now, "morally", CIL should be able to process any C file that the compiler can
process - but on a 32-bit machine this does break down here. I expect the right
thing to do would be to modify CIL to use Nativeint library for storying array
sizes.
--
>Comment By: Gabriel Kerneis (kerneis)
Date: 2013-02-15 14:50
Message:
OK, Jim. I wonder if this is not some legacy check, and everything else
(except lenOfArray and bitsSizeOf et al.) woud work correctly now. Could
you try the stupid following patch, please?
Many thanks,
Gabriel
--- a/src/frontc/cabs2cil.ml
+++ b/src/frontc/cabs2cil.ml
@@ -2839,7 +2839,7 @@ and doType (nameortype: attributeClass) (* This is
AttrName if we are doing
let size = mul_cilint elems (cilint_of_int elsz) in
begin
try ignore(int_of_cilint size)
- with _ -> E.s (error "Length of array is too large")
+ with _ -> ignore (warn "Length of array is too large")
end
| l ->
if isConstant l then
--
Comment By: Jim Grundy (jim_grundy)
Date: 2013-02-15 14:24
Message:
Hi Gabriel
We're doing a source-to-source transform using Cil as a library. The error
we are getting is:
Length of array is too large
Which looks like it comes from frontc/cabs2cil.ml/doType
I'm not sure what's going on here ... but my guess is that it is tryng to
compute the size of the array to record it as an attirbute, but the
atributes use OCaml ints rather than 64-bit ints so it won't fit.
The example program is just this - run with a 32-bit OCaml build on a
64-bit Windows machine.
char big_array[1073741824];
int main () {
return 0;
}
All the best
Jim
--
Comment By: Gabriel Kerneis (kerneis)
Date: 2013-02-15 14:00
Message:
I meant CIL 1.4, 1.7 does not even exist...
--
Comment By: Gabriel Kerneis (kerneis)
Date: 2013-02-15 13:49
Message:
Since CIL 1.7 (I think), length of arrays is stored as a CInt64 when it is
known explicitely. However, Cil.lenOfArray converts it to int
(Cil.bitsSizeOf also has a similar behaviour, see bug 1641570). What are
you trying to do and how does CIL fail exactly when you process these
programs? Could you post a (script to generate) an example program?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3604915&group_id=138953
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
CIL-users mailing list
CIL-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cil-users
[CIL users] [ cil-Bugs-3604915 ] Legal, but large, static arrays can fail.
Bugs item #3604915, was opened at 2013-02-15 13:29
Message generated for change (Comment added) made by jim_grundy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3604915&group_id=138953
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: CIL core (parser, visitor, etc)
Group: Bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Grundy (jim_grundy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Legal, but large, static arrays can fail.
Initial Comment:
We've encounterd embedded programs that carve out large static arrays ... and
they compile and run correctly, but CIL can't process them because the array's
are too big.
In particular, CIL appears to use an OCaml int for an array size, but since
OCaml int's are 1) signed 2) 1-bit shorter than machine ints to facilitate fast
garbage collection; it is possible - and we do - have arrays with a size that
is bigger than can be represented with an OCaml int.
Natrually this is a problem in practice only on 32-bit builds, but since all
the pre-combiled Windows OCaml builds are 32-bit the problem occurs.
I believe this to be the cause because if I set the size to be one byte smaller
than the largest 2s complement number representable in 31 bits it works.
Now, "morally", CIL should be able to process any C file that the compiler can
process - but on a 32-bit machine this does break down here. I expect the right
thing to do would be to modify CIL to use Nativeint library for storying array
sizes.
--
>Comment By: Jim Grundy (jim_grundy)
Date: 2013-02-15 15:09
Message:
Thanks ... will try, but I'm about to get on a plane ... so it may take me
1.5 weeks :-(. I will try to get someone to try for me while I'm out.
--
Comment By: Gabriel Kerneis (kerneis)
Date: 2013-02-15 14:50
Message:
OK, Jim. I wonder if this is not some legacy check, and everything else
(except lenOfArray and bitsSizeOf et al.) woud work correctly now. Could
you try the stupid following patch, please?
Many thanks,
Gabriel
--- a/src/frontc/cabs2cil.ml
+++ b/src/frontc/cabs2cil.ml
@@ -2839,7 +2839,7 @@ and doType (nameortype: attributeClass) (* This is
AttrName if we are doing
let size = mul_cilint elems (cilint_of_int elsz) in
begin
try ignore(int_of_cilint size)
- with _ -> E.s (error "Length of array is too large")
+ with _ -> ignore (warn "Length of array is too large")
end
| l ->
if isConstant l then
--
Comment By: Jim Grundy (jim_grundy)
Date: 2013-02-15 14:24
Message:
Hi Gabriel
We're doing a source-to-source transform using Cil as a library. The error
we are getting is:
Length of array is too large
Which looks like it comes from frontc/cabs2cil.ml/doType
I'm not sure what's going on here ... but my guess is that it is tryng to
compute the size of the array to record it as an attirbute, but the
atributes use OCaml ints rather than 64-bit ints so it won't fit.
The example program is just this - run with a 32-bit OCaml build on a
64-bit Windows machine.
char big_array[1073741824];
int main () {
return 0;
}
All the best
Jim
--
Comment By: Gabriel Kerneis (kerneis)
Date: 2013-02-15 14:00
Message:
I meant CIL 1.4, 1.7 does not even exist...
--
Comment By: Gabriel Kerneis (kerneis)
Date: 2013-02-15 13:49
Message:
Since CIL 1.7 (I think), length of arrays is stored as a CInt64 when it is
known explicitely. However, Cil.lenOfArray converts it to int
(Cil.bitsSizeOf also has a similar behaviour, see bug 1641570). What are
you trying to do and how does CIL fail exactly when you process these
programs? Could you post a (script to generate) an example program?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3604915&group_id=138953
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
CIL-users mailing list
CIL-users@li
[CIL users] [ cil-Bugs-3604915 ] Legal, but large, static arrays can fail.
Bugs item #3604915, was opened at 2013-02-15 13:29
Message generated for change (Comment added) made by
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3604915&group_id=138953
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: CIL core (parser, visitor, etc)
Group: Bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Grundy (jim_grundy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Legal, but large, static arrays can fail.
Initial Comment:
We've encounterd embedded programs that carve out large static arrays ... and
they compile and run correctly, but CIL can't process them because the array's
are too big.
In particular, CIL appears to use an OCaml int for an array size, but since
OCaml int's are 1) signed 2) 1-bit shorter than machine ints to facilitate fast
garbage collection; it is possible - and we do - have arrays with a size that
is bigger than can be represented with an OCaml int.
Natrually this is a problem in practice only on 32-bit builds, but since all
the pre-combiled Windows OCaml builds are 32-bit the problem occurs.
I believe this to be the cause because if I set the size to be one byte smaller
than the largest 2s complement number representable in 31 bits it works.
Now, "morally", CIL should be able to process any C file that the compiler can
process - but on a 32-bit machine this does break down here. I expect the right
thing to do would be to modify CIL to use Nativeint library for storying array
sizes.
--
Comment By: Eran T ()
Date: 2013-02-21 05:58
Message:
Hi Gabriel,
Jim Grundy has asked me to check the patch you sent for cabs2cil.ml,
and seems to be working as expected: those messages are sent out as
warnings instead of errors.
Thanks!
Eran Talmor
--
Comment By: Jim Grundy (jim_grundy)
Date: 2013-02-15 15:09
Message:
Thanks ... will try, but I'm about to get on a plane ... so it may take me
1.5 weeks :-(. I will try to get someone to try for me while I'm out.
--
Comment By: Gabriel Kerneis (kerneis)
Date: 2013-02-15 14:50
Message:
OK, Jim. I wonder if this is not some legacy check, and everything else
(except lenOfArray and bitsSizeOf et al.) woud work correctly now. Could
you try the stupid following patch, please?
Many thanks,
Gabriel
--- a/src/frontc/cabs2cil.ml
+++ b/src/frontc/cabs2cil.ml
@@ -2839,7 +2839,7 @@ and doType (nameortype: attributeClass) (* This is
AttrName if we are doing
let size = mul_cilint elems (cilint_of_int elsz) in
begin
try ignore(int_of_cilint size)
- with _ -> E.s (error "Length of array is too large")
+ with _ -> ignore (warn "Length of array is too large")
end
| l ->
if isConstant l then
--
Comment By: Jim Grundy (jim_grundy)
Date: 2013-02-15 14:24
Message:
Hi Gabriel
We're doing a source-to-source transform using Cil as a library. The error
we are getting is:
Length of array is too large
Which looks like it comes from frontc/cabs2cil.ml/doType
I'm not sure what's going on here ... but my guess is that it is tryng to
compute the size of the array to record it as an attirbute, but the
atributes use OCaml ints rather than 64-bit ints so it won't fit.
The example program is just this - run with a 32-bit OCaml build on a
64-bit Windows machine.
char big_array[1073741824];
int main () {
return 0;
}
All the best
Jim
--
Comment By: Gabriel Kerneis (kerneis)
Date: 2013-02-15 14:00
Message:
I meant CIL 1.4, 1.7 does not even exist...
--
Comment By: Gabriel Kerneis (kerneis)
Date: 2013-02-15 13:49
Message:
Since CIL 1.7 (I think), length of arrays is stored as a CInt64 when it is
known explicitely. However, Cil.lenOfArray converts it to int
(Cil.bitsSizeOf also has a similar behaviour, see bug 1641570). What are
you trying to do and how does CIL fail exactly when you process these
programs? Could you post a (script to generate) an example program?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3604915&group_id=138953
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/s
[CIL users] [ cil-Bugs-3604915 ] Legal, but large, static arrays can fail.
Bugs item #3604915, was opened at 2013-02-15 13:29
Message generated for change (Comment added) made by kerneis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3604915&group_id=138953
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: CIL core (parser, visitor, etc)
Group: Bug
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Grundy (jim_grundy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Legal, but large, static arrays can fail.
Initial Comment:
We've encounterd embedded programs that carve out large static arrays ... and
they compile and run correctly, but CIL can't process them because the array's
are too big.
In particular, CIL appears to use an OCaml int for an array size, but since
OCaml int's are 1) signed 2) 1-bit shorter than machine ints to facilitate fast
garbage collection; it is possible - and we do - have arrays with a size that
is bigger than can be represented with an OCaml int.
Natrually this is a problem in practice only on 32-bit builds, but since all
the pre-combiled Windows OCaml builds are 32-bit the problem occurs.
I believe this to be the cause because if I set the size to be one byte smaller
than the largest 2s complement number representable in 31 bits it works.
Now, "morally", CIL should be able to process any C file that the compiler can
process - but on a 32-bit machine this does break down here. I expect the right
thing to do would be to modify CIL to use Nativeint library for storying array
sizes.
--
>Comment By: Gabriel Kerneis (kerneis)
Date: 2013-03-21 12:48
Message:
Thanks for the report, Jim. This should be fixed in the repo now.
--
Comment By: Eran T ()
Date: 2013-02-21 05:58
Message:
Hi Gabriel,
Jim Grundy has asked me to check the patch you sent for cabs2cil.ml,
and seems to be working as expected: those messages are sent out as
warnings instead of errors.
Thanks!
Eran Talmor
--
Comment By: Jim Grundy (jim_grundy)
Date: 2013-02-15 15:09
Message:
Thanks ... will try, but I'm about to get on a plane ... so it may take me
1.5 weeks :-(. I will try to get someone to try for me while I'm out.
--
Comment By: Gabriel Kerneis (kerneis)
Date: 2013-02-15 14:50
Message:
OK, Jim. I wonder if this is not some legacy check, and everything else
(except lenOfArray and bitsSizeOf et al.) woud work correctly now. Could
you try the stupid following patch, please?
Many thanks,
Gabriel
--- a/src/frontc/cabs2cil.ml
+++ b/src/frontc/cabs2cil.ml
@@ -2839,7 +2839,7 @@ and doType (nameortype: attributeClass) (* This is
AttrName if we are doing
let size = mul_cilint elems (cilint_of_int elsz) in
begin
try ignore(int_of_cilint size)
- with _ -> E.s (error "Length of array is too large")
+ with _ -> ignore (warn "Length of array is too large")
end
| l ->
if isConstant l then
--
Comment By: Jim Grundy (jim_grundy)
Date: 2013-02-15 14:24
Message:
Hi Gabriel
We're doing a source-to-source transform using Cil as a library. The error
we are getting is:
Length of array is too large
Which looks like it comes from frontc/cabs2cil.ml/doType
I'm not sure what's going on here ... but my guess is that it is tryng to
compute the size of the array to record it as an attirbute, but the
atributes use OCaml ints rather than 64-bit ints so it won't fit.
The example program is just this - run with a 32-bit OCaml build on a
64-bit Windows machine.
char big_array[1073741824];
int main () {
return 0;
}
All the best
Jim
--
Comment By: Gabriel Kerneis (kerneis)
Date: 2013-02-15 14:00
Message:
I meant CIL 1.4, 1.7 does not even exist...
--
Comment By: Gabriel Kerneis (kerneis)
Date: 2013-02-15 13:49
Message:
Since CIL 1.7 (I think), length of arrays is stored as a CInt64 when it is
known explicitely. However, Cil.lenOfArray converts it to int
(Cil.bitsSizeOf also has a similar behaviour, see bug 1641570). What are
you trying to do and how does CIL fail exactly when you process these
programs? Could you post a (script to generate) an example program?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=742140&aid=3604915&group_id=138953
