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

Richard Smith - zygoloid via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Apr 22 17:47:09 PDT 2019

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?

  rC Clang



More information about the cfe-commits mailing list