ro marked an inline comment as done. ro added a comment. In D64793#1597550 <https://reviews.llvm.org/D64793#1597550>, @jyknight wrote:
> Is this really necessary? Users don't typically pass -std= to the driver for > linking anyways (what do you even pass if you've compiled both C and C++ > code?) so this seems a rather odd way to control behavior. I fear it is necessary: at least it matches documented behaviour of both the Sun/Oracle Studio compilers and gcc. The -std= options usually get passed to the linking step because CFLAGS is added to the options as well. In the mixed-language case, you have to link with the C++ compiler, and the !isGNUMode test deals with both languages alike. > How about instead just adding "values-xpg6.o" unconditionally, alongside the > current unconditional "values-Xa.o", and just forget about the xpg4 and Xc > modes? If all else fails, that would have to be the last fallback. I'd rather do things correctly, though. ================ Comment at: lib/Driver/ToolChains/Solaris.cpp:16 #include "clang/Driver/Options.h" +#include "clang/Frontend/LangStandard.h" #include "llvm/Option/ArgList.h" ---------------- jyknight wrote: > I'm not sure that's an acceptable dependency -- I think Driver probably is > not supposed to depend on Frontend. If so, I guess LangStandard should move > to clang/Basic/. Which also means moving InputKind from > clang/include/clang/Frontend/FrontendOptions.h. > > (Maybe someone else can weigh in on this question?) I wondered about this myself, including frontend code in the driver might be considered a layering violation. I certainly need guidance here what is and isn't acceptable here. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64793/new/ https://reviews.llvm.org/D64793 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
