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

rsmith added a comment. In D60943#1475038 , @void wrote: > In D60943#1474926 , @rsmith wrote: > > > Is `"n"` really special in this regard, or is it just the first one that > > we've encountered? > > > I think

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

void added a comment. In D60943#1474926 , @rsmith wrote: > In D60943#1474899 , @void wrote: > > > Here's the motivating bug report: > > https://bugs.llvm.org/show_bug.cgi?id=41027 > > > Thanks, that's

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

rsmith added a comment. In 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

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

void added a comment. Here's the motivating bug report: https://bugs.llvm.org/show_bug.cgi?id=41027 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. :-( That said, I

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

rsmith added a comment. I don't like making the validity of an input depend on optimizations, but I presume this is necessary to build Linux or similar? I'd be more comfortable with this if we still did the eager check if the enclosing function doesn't have the `always_inline` attribute. Is

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

void added a comment. In D60943#1474091 , @joerg wrote: > I'm in the process of testing this, but feedback will take a bit. > > On the more meaty parts of this change, I think further iterations will be > necessary in-tree to extend this to the other

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

joerg added a comment. I'm in the process of testing this, but feedback will take a bit. On the more meaty parts of this change, I think further iterations will be necessary in-tree to extend this to the other constraints. Repository: rC Clang CHANGES SINCE LAST ACTION

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

void added a comment. This relies upon D60943 . Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60943/new/ https://reviews.llvm.org/D60943 ___ cfe-commits mailing list

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

void updated this revision to Diff 195994. void added a comment. Herald added a subscriber: eraman. Fix test. Use "e" instead of "n". Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60943/new/ https://reviews.llvm.org/D60943 Files: lib/CodeGen/CGStmt.cpp

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

void updated this revision to Diff 195992. void added a comment. Put constraint string check in the correct place. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60943/new/ https://reviews.llvm.org/D60943 Files: lib/CodeGen/CGStmt.cpp

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

void created this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. An inline asm call may result in an immediate input value after inlining. Therefore, don't emit a diagnostic here if the input isn't an immediate. Repository: rC Clang