On Tue, Mar 28, 2017 at 10:14:43PM +0100, Dibyendu Majumdar wrote:
> >>>
> >>> 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?
I doesn't know much this area but I think it's OK.
I think the bug is that sparse-llvm doesn't use the size as it
is given: in the SYM_NODE.
I bet that if you look at the code for sizeof, you will see that
the size is taken from the SYM_NODE and not what's under it.
As far as I understand (but again, I don't know much here) it's the
purpose of SYM_NODEs to do things like that.
> I think that there is a bug in examine_node_type() in symbol.c - it
> should set the base_type's bit_size perhaps? See the line marked as
> FIX below,
>
> /* Unsized array? The size might come from the initializer.. */
> if (bit_size < 0 && base_type->type == SYM_ARRAY) {
> struct expression *initializer = get_symbol_initializer(sym);
> if (initializer) {
> struct symbol *node_type = base_type->ctype.base_type;
> int count = count_array_initializer(S, node_type, initializer);
>
> if (node_type && node_type->bit_size >= 0)
> bit_size = array_element_offset(S->C->target, node_type->bit_size, count);
> base_type->bit_size = bit_size; /*** FIX set base_type->bit_size ***/
> }
> }
I'm far from sure.
Yes, here it will works but in general you have no idea who else is
using the base_type. For other users it may be legitimally still
be unsized.
-- Luc
--
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
