On Thu, Nov 24, 2016 at 2:33 AM, Nicolai Stange <nicstange@xxxxxxxxx> wrote: > > While doing this, I recognized that sparse's current constant expression > tagging scheme was quite limited and I had to touch everything related > to it anyway. So I asked on this list on whether it would be a good > thing to let sparse be more strict than gcc in this regard and the > feedback was that it certainly would (at user option). Good. Thanks for reminding of that. So ideally this is under a more strict options. > > Can you tell which one? If not, would resending this series help? > Yes, I can. But never mind that point as I reply in previous email. I figure you do the same work in the evaluation stage now. No, please don't send the series again. I have a script system to process the patches now. So no patch will be missed from now on. > So, if the above testcase really fails after this series, it's either a > bug or an artifact of having this typeof() in there (or both), I > think. Never mind that. >> Integer constant expression can be tested as: >> >> !(flags & ( Addr | Float) ) && flag >> >> Arithmetic constant expression can be tested as: >> >> !(flags & Addr) ) && flag >> >> Do you see any problem with this internal representation? > > (int)0.0 is an integer constant expression. > > In your scheme, it would have "composite op" and "float" set? > The integer constant expression test you proposed above would > fail in this case. > (int) 0.0 will express as "Composite op" and "Int const" set. Cast is a special operation it will strip the "float" and convert it to "int". After all that is what cast does. It will not change your patch behavior and warning etc, it is just a internal representation difference. How the constant expression bits are store and interpreted. Chris -- 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
