cor3ntin wrote: Thanks.
A few comments: - I feel like the constant evaluation warnings are a regression. As a user, i want to know that the variable was not initialized. whether it is indeterminate or not does not matter during constant evaluation. I do not mind tracking it, but i don't think it should be user-observable. The only significant change in expr.const is https://eel.is/c++draft/expr.const#9.8 So we should keep saying "variable 'x' is uninitialized when used here" - The wording tries to be very specific about how bit_cast preserves indeterminate-ness, we probably should have tests for that. Then there is the load bearing aspect of this paper. This sentence https://eel.is/c++draft/intro.abstract#7.sentence-1 > An implementation should issue a diagnostic when such an operation is > executed[.](https://eel.is/c++draft/intro.abstract#7.sentence-1) There are a couple valid interpretations - We should do static analysis (which you are doing) - We should diagnose at runtime somehow. I we wanted to diagnose at runtime somehow, which could be work for a future PR, there are a few ways to go about it - Sanitizers should know about indeterminate and erroneous behavior (but we already diagnose reading indeterminate value in memsan) - We should check that this implementation does not make sanitizers worse - Debuggers might want to know about the indeterminate attribute - Then there is the question of whether we want to force more instrumentation in clang somehow - although that is probably premature. https://github.com/llvm/llvm-project/pull/177614 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
