rjmccall added a comment. In the cases where we can emit nonnull, I agree that we should be able to safely use dereferenceable for the non-virtual data size of of the type. I'm not too concerned about people calling methods on entirely the wrong type, especially to the relatively small degree that deferenceable can actually cause miscompiles.
Getting back to the original discussion, I understand the desire to be strict about the language standard by default, but that's a lot easier when we're talking about static properties of source than when we're talking about dynamic properties of programs. Nobody is well-served by us introducing a compiler option that will only have to be widely disabled, especially if the only way to disable it also disables a much broader class of optimization, as appears to be the case in GCC. I propose embracing a three-tier system. There are a lot of optimizations (current and future) that are only made legal by strict interpretation of the language standard. Some of those optimizations are reasonable for us to turn on by default; others are more treacherous. We should recommend that programmers use of three different options: -flanguage-optimization=strict, -flanguage-optimization=lax, or the default (-flanguage-optimization=cautious?). Each will imply a different set of defaults for each of the language-informed optimizations. Programmers who feel comfortable that their programs are conforming can opt in to strict optimization; programmers who are very worried about it can opt out of even our more conservative optimizations (like -fno-strict-aliasing). http://reviews.llvm.org/D17993 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
