[PATCH] D60943: Delay diagnosing "n" constraint until after inlining

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D60943#1474899 <https://reviews.llvm.org/D60943#1474899>, @void wrote:

> Here's the motivating bug report: https://bugs.llvm.org/show_bug.cgi?id=41027


Thanks, that's illuminating. OK, if we want to support that code, then there's really not much validation we can do in the frontend for constraints that require immediate constants. Is `"n"` really special in this regard, or is it just the first one that we've encountered?

> In general, I agree with you that diagnostics shouldn't depend on optimization levels, but inline assembly subverts this paradigm because it was originally a gcc extension. :-(

There is a question of how much weird stuff we should accept in the name of GCC compatibility. In this case, the fact that the frontend rejects seems like the tip of an iceberg: the code in the PR is also relying on the control flow of the `&&` inside the `if` to be emitted in a very particular way (or to be optimized to that form), and for dead-code elimination to be considered and to actually fire, and probably more things besides. Do we at least still produce a nice diagnostic if the value ends up not being a constant?


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60943/new/

https://reviews.llvm.org/D60943