ASDenysPetrov added a comment. @NoQ
> If we ever prove that strict aliasing is violated on a given execution path > (while being enabled), the ideal thing to do is to terminate the analysis > immediately by generating a sink. We can then optionally develop a checker > that emits a warning in such cases. thinking about warnings I assume that the Store will produce `UndefinedVals` and //Undef-related// checkers will catch them. But yes, you're right. They wouldn't know anything about the origin of such `UndefinedVals`. > For the cases where you eliminate possibilities through recognizing strict > aliasing, I wonder if a note can be added to the bug report to notify the > user that the strict aliasing rule was invoked to add a certain assumption. I didn't elaborate an idea with a checker yet but, I think, it can be the next step. What about a mechanism which would store the reason of UndefinedVal for existing checkers? It could make any checker more detailed and flexible. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D110927/new/ https://reviews.llvm.org/D110927 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
