clang++-mp-4.0 -stdlib=macports-libstdc++ should be in C++11 mode by default

[mojca (Mojca Miklavec)]

Related to #53194, #53329, #53330.

Compare the following output on < 10.9:

> g++-mp-6 test.cpp -o test
# OK

> clang++-mp-4.0 -stdlib=libc++ test.cpp -o test
# OK

> clang++-mp-4.0 test.cpp -o test
test.cpp:1:10: fatal error: 'regex' file not found
#include <regex>
         ^~~~~~~
1 error generated.

> clang++-mp-4.0 -stdlib=macports-libstdc++ test.cpp -o test
In file included from test.cpp:1:
In file included from /opt/local/include/gcc6/c++/regex:35:
/opt/local/include/gcc6/c++/bits/c++0x_warning.h:32:2: error: This file requires compiler and library support for the ISO C++ 2011 standard. This support must be
      enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support \
 ^
1 error generated.

The file test.cpp is a simple #include <regex> int main() { return 0; }

While this can be avoided by adding a -std=c++11 flag, the behaviour would be much more consistent if the compiler would assume C++11 by default.

See also #53625 where this first came up.

[jeremyhu (Jeremy Huddleston Sequoia)]

I'm certainly fine letting -stdlib=macports-libstdc++ imply -std=c++11. Feel free to make that change. Of course, -stdlib=libstdc++ should not change.

[mojca (Mojca Miklavec)]

Marcus, since you were patching this, do you have any idea where/how to fix the behaviour? I'm not too familiar with llvm sources. I did some grep-ing for various variables, I found places like Opts.CPlusPlus11 = Std.isCPlusPlus11(), but it's so much code that it's nearly impossible to know where the decision is made about whether or not C++11 should be the default.

[kencu (Ken)]

I'm thinking that this bit in Marcus' patch:

+  case ToolChain::CST_MacPortsLibstdcxx:
+    if (getVFS().exists("@@MACPORTS_libstdc++@@")) {
+      CmdArgs.push_back("@@MACPORTS_libstdc++@@");
+      return;
+    }
+    CmdArgs.push_back("-lstdc++");
+    break;

could be this instead:

+    CmdArgs.push_back("-lstdc++");
+    CmdArgs.push_back("-std=c++11");

Edit - the following did not work. -- Ken

there's another spot at the very end of the patch that does the same kind of push_back, and probably the same extra addition should go there, although the way it's written right now it might also affect CST_Libstdcxx and so we would need a separate break; item for each CST.

   case ToolChain::CST_Libstdcxx:
+  case ToolChain::CST_MacPortsLibstdcxx:
     CmdArgs.push_back("-lstdc++");
     break;

like this maybe:

   case ToolChain::CST_Libstdcxx:
     CmdArgs.push_back("-lstdc++");
     break;
   case ToolChain::CST_MacPortsLibstdcxx:
     CmdArgs.push_back("-lstdc++");
     CmdArgs.push_back("-std=c++11");
     break;

[kencu (Ken)]

Yeah, I'm not so sure about that now that I look at it -- this would be happening while the build line is being parsed, so would it work to push back the std= onto the build line again? Would it get re-parsed?

Perhaps you'd have to find out what -std=c++11 invokes when being parsed, and do that. Is setting this enough, I wonder:

Opts.CPlusPlus11 = Std.isCPlusPlus11()

There might be more to it.

And then what if there is some other -std= line on the build line? Presumably that should win.

Enough speculation, I guess. Have to dig in and try different things to sort this out.

[kencu (Ken)]

It would be rather trivial to add

configure.cxxflags-append -std=c++11

in the right place in the cxx11 1.1 portgroup, as presumably any code that is calling that portgroup is c++11 compatible, after all.

[kencu (Ken)]

There is a bit of logic in tools/clang/lib/Driver/Tools.cpp where the build line parsing logic looks for a std language standard to be set, and if there is none, appears to offer one up for c, but apparently not for c++ unless you're on Windows, if I read this correctly.

    if (!types::isCXX(InputType))
      Args.AddAllArgsTranslated(CmdArgs, options::OPT_std_default_EQ, "-std=",
                                /*Joined=*/true);
    else if (IsWindowsMSVC)
      ImplyVCPPCXXVer = true;

ImplyVCPPCXXVer = true leads to a block of code later down that sets a standard language on Windows.

So far, this would seem to me to be the most likely place to add in a default c++ language standard, if a suitable test for darwin && stdlib=macports-libsdtc++ could be generated. A workaround such as the one that is done for MSVC could be similarly implemented for macports-libstdc++.

I guess the real question is whether this is a good plan right now. gcc has moved it's default standard, but clang so far has not.

[kencu (Ken)]

FYI, it looks like there was some recent discussion going on about defaulting to c++11 or c++14 on the clang developers mailing list: <​http://clang-developers.42468.n3.nabble.com/Setting-default-dialect-to-C-11-td4055489.html>.

This thread is also germane to this topic <​http://clang-developers.42468.n3.nabble.com/RFC-Default-language-standard-mode-policy-td4052354.html>.

[kencu (Ken)]

See <​https://reviews.llvm.org/D40948>. This commit changes the default language standard to c++14. It should be in the clang-6.0 release.

I was way off -- there is a one-liner to change the language standard that I didn't find.

[kencu (Ken)]

the llvm devs decided ath clang-7.0+ will default to c++17