On Wed, Mar 29, 2017 at 4:41 PM, Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> wrote: > Hi Luc, > >> >> Okay thank you for the insight. It seems then that sparse-llvm is not >> handing this correctly. >> > > I looked at this again briefly today. I think that not having the size > information on the array type poses some problems. > > + will instructions have access to the SYM_NODE always? It doesn't > appear to be the case. The SYM_NODE is present/only added when needed. Of course, it's possible that it's somehow stripped in sparse-llvm. > + sparse-llvm caches the symbol's type in symbol->aux. For array > types, we would still need to do this - storing the type against > SYM_NODE objects is probably not correct. I don't see why it shouldn't be correct. > So I feel that given that the size is an integral part of the array > type then it makes sense that it should be present on the array type. I feel some sympathy for the argument here but ... there are other infos stored in the SYM_NODE that *can't* be stored in the symbol underneath it. I'm thinking about the exact type, the modifiers, for example. You will soon or later need to handle the SYM_NODE anyway; stripping it and trying to directly use the base type under is in general wrong. -- 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
