Re: sparse-llvm array size computation issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 28 March 2017 at 21:49, Luc Van Oostenryck
<luc.vanoostenryck@xxxxxxxxx> wrote:
> On Tue, Mar 28, 2017 at 10:41 PM, Dibyendu Majumdar
> <mobile@xxxxxxxxxxxxxxx> wrote:
>> On 28 March 2017 at 21:25, Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> wrote:
>>> I am investigating an issue with following test case:
>>>
>>> int main(void)
>>> {
>>> const char *names[] = {
>>> "dibyendu",
>>> "majumdar",
>>> NULL,
>>> };
>>> return 0;
>>> }
>>>
>>> The issue here is that sparse-llvm thinks the array size is zero:
>>>
>>> define i32 @main() {
>>> L0:
>>>   %names_0000026DE9D2DDA8. = alloca [0 x i8*]
>>>
>>> It appears that sparse is correctly calculating the size of the array
>>> in examine_node_type() in symbol.c, but by the time the symbol gets to
>>> sparse-llvm the bit_size is somehow changed to -1. I haven't yet
>>> tracked down where this is happening.
>>>
>>
>> Looks like the computed bit_size is being held on the SYM_NODE but
>> sparse-llvm looks as the bit_size field in the SYM_ARRAY node. Does
>> this sound like a problem - i.e. somehow the SYM_ARRAY is not getting
>> its size set?
>
> What happening if you change to : return sizeof(names); ?
>

sizeof works okay.
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Newbies FAQ]     [LKML]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Trinity Fuzzer Tool]

  Powered by Linux