On Tue, Jul 23, 2013 at 10:56 AM, Reid Kleckner <[email protected]> wrote: > I think we want to have a whitelist of "clang options" that are distinct > from gcc options, rather than blacklisting a troublesome few (-MD) as > GCCOptions. That seemed to be the main conclusion of the discussion on > cfe-dev.
I thought for a while that blacklisting "a troublesome few" would make for a much shorter list than whitelisting "clang options", but now that I look at the file again, I see that there's a very large amount of options that don't apply to clang-cl, and lots of conflicts too. I've attached a new patch that does the whitelist approach, and starts with a pretty short whitelist. I figure we can add more stuff too it as needed. > We obviously don't want to add Flags<[ClangOption]> to every option in > f_Group and f_clang_Group, so there'll have to be some tablegen magic in > there. I'm not sure we want to whitelist everything in f_Group and f_clang_Group, though. For example, -fapple-kext is in f_Group, which doesn't make sense for clang-cl. In g_clang_Group we have the sanitizer options, maybe we want to hold off exposing those options until we support them? There's also -fno-inline, which maybe we don't want to expose since clang-cl will have /Ob0? Thanks, Hans > On Mon, Jul 22, 2013 at 8:38 PM, Hans Wennborg <[email protected]> wrote: >> >> Hi all, >> >> The attached patch makes clang-cl handle the /? and /help command-line >> flags. >> >> These are both just aliases to the regular -help flag, but this puts >> the code in place for accepting (and printing as part of the help >> message) different flags depending on the driver mode. >> >> Please take a look! >> >> Thanks, >> Hans
first-cl-flags-2.diff
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
