void added a comment. In D54355#1326494 <https://reviews.llvm.org/D54355#1326494>, @craig.topper wrote:
> I'm seeing a case where an inline assembly 'n' constraint is behaving > differently in -O0 now. Previously we would evaluate the __builtin_constant_p > as part of the EvaluateAsInt call in CodeGenFunction::EmitAsmInput, but I > think we're not doing that now. This causes us to fail later because the > constraint wasn't satisfied since we were in -O0 and thus we didn't optimize > the rest of the expression. The test case we have is a nasty mix of > __builtin_constant_p, __builtin_choose_expr, and __builtin_classify_type. I > can see about sharing it if needed. `__builtin_constant_p()` is known to have different semantics at `-O0` than it does during optimizations. That said, we shouldn't be intentionally generating incorrect code. Could you test it against gcc to see if it has the same semantics? Otherwise, please add a testcase. :-) Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D54355/new/ https://reviews.llvm.org/D54355 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
