<div dir="ltr">[Summarizing some offline discussion for the list]<div><br></div><div>Maybe the way forward is something like this.  First, underlying all the argv[0] name heuristics is a switch like --driver-flavor=gcc / --driver-flavor=cl and maybe g++.</div>
<div><br></div><div>We add two more flags to the option table: GCCOption and ClangOption.  When in gcc driver mode, only clang and gcc options are accepted.  For example, -fcolor-diagnostics is our preferred spelling of that option, so it gets the clang flag, and -fdiagnostics-color gets the gcc flag.  When using the cl driver flavor, we accept cl args and clang args.</div>
<div><br></div><div>We should only put the ClangOption flag on options whose spellings don't conflict with cl.exe and that fall into the buckets Chandler mentioned: high-level double dash, or non-conflicting single character group prefix.</div>
<div><br></div><div>GCCOption goes on everything that gcc accepts.  This is actually handy because there are users who do things like run clang -fsyntax-only and then invoke gcc for codegen, and they need to know the subset of flags that gcc supports.</div>
<div><br></div><div>One open question is, is it even worth creating an escape to allow users of clang-cl to get at the gcc options, or do we tell them not to do that, or use the private -cc1 options as a hacky workaround?</div>
<div><br></div><div>Similarly, we expect we'll want to be able to invoke cl.exe from clang-cl if someone asks for an unimplemented feature like /clr:pure.</div><br></div>