[PATCH] D64793: [Driver] Properly use values-X[ca].o, values-xpg[46].o on Solaris

Tue Jul 23 10:58:42 PDT 2019

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