<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Paul,<div class=""><br class=""></div><div class="">When round-tripping, we don't textually compare the generated command-line with the original. That's because the original is not guaranteed to be canonical: it may contain aliased options and the options may be in arbitrary order.</div><br class="">What we could have done is compare the CompilerInvocation created from the original command-line with CompilerInvocation created from the generated command-line. However, for that we'd need to define operator== and remember to update it when adding new CompilerInvocation fields. There was an attempt to generate this automatically: <a href="https://reviews.llvm.org/D86290" class="">https://reviews.llvm.org/D86290</a> (Move all fields of '-cc1' option related classes into def file databases), but got reverted.<div class=""><br class=""></div><div class="">Currently, we compare CompilerInvocation (B) created from the generated command-line with CompilerInvocation (C) created from command-line generated from (B): <a href="https://github.com/llvm/llvm-project/blob/92f9852/clang/lib/Frontend/CompilerInvocation.cpp#L618" class="">https://github.com/llvm/llvm-project/blob/92f9852/clang/lib/Frontend/CompilerInvocation.cpp#L618</a>. That ensures the generation is deterministic, but detecting forgotten options is still up to the test suite.</div><div class=""><br class=""></div><div class="">AFAIK LLVM's TargetOptions are constructed from parts of Clang's CompilerInvocation and get end-to-end tested in CodeGen. Am I missing something here?</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Jan</div><div class=""><br class=""><div class=""><div><blockquote type="cite" class=""><div class="">On 12.5.2021, at 22:36, via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">After the recent refactoring to Clang option handling that introduced<br class="">"round-tripping" we had a couple of issues come up with options that<br class="">we have defined downstream. In some cases I believe these showed up <br class="">as test failures and got fixed by adding code to GenerateCodeGenArgs; <br class="">that's fine. And right now I'm doing the marshalling thing so we can <br class="">remove some local patches to CompilerInvocation (yay!).<br class=""><br class="">But we also had other options that silently weren't propagated, and<br class="">we discovered this only by chance. I would rather have had them show<br class="">up as test failures. This likely points to an inadequacy in our test<br class="">coverage, but it brings me to a question:<br class=""><br class="">When round-tripping is enabled, is the re-generated command line<br class="">textually compared to the original command line in some way? If it <br class="">is, I'd have expected it to catch these cases, because some option <br class="">on the original CC1 command line wouldn't be in the re-generated <br class="">command. But, that didn't happen.<br class=""><br class="">For options that Clang itself does something with, presumably tests<br class="">for how the option affects Clang's own behavior would catch issues<br class="">(I'm pretty sure that's how we found the cases we did, although I<br class="">wasn't the one to do that work). But in the case of a Clang option <br class="">that just gets passed down to LLVM (through LLVM's TargetOptions, say)<br class="">it's not clear there's a good way to test that actually happens.<br class=""><br class="">Thanks,<br class="">--paulr<br class=""><br class="">_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>