Is Clang 3.6 still supported as host compiler for libcxx?

Hello,

I couldn't find any definite information on which compiler versions are supported for building libcxx.

When trying to build it with clang 3.6.2 or earlier verions, I run into the following compilation error:

projects/libcxx/src/experimental/filesystem/path.cpp:286:14: error: no matching constructor for initialization of 'string_view_t' (aka 'basic_string_view<char>')
      return string_view_t{__pn_}.substr(0, e + 1);
             ^ ~~~~~~~
projects/libcxx/include/string_view:200:2: note: candidate constructor not viable: no known conversion from 'const string_type' (aka 'const basic_string<value_type>') to 'const
      std::__1::basic_string_view<char, std::__1::char_traits<char> > &' for 1st argument
        basic_string_view(const basic_string_view&) _NOEXCEPT = default;
        ^
projects/libcxx/include/string_view:215:2: note: candidate constructor not viable: no known conversion from 'const string_type' (aka 'const basic_string<value_type>') to 'const char *' for 1st argument
        basic_string_view(const _CharT* __s)
        ^
projects/libcxx/include/string_view:197:2: note: candidate constructor not viable: requires 0 arguments, but 1 was provided
        basic_string_view() _NOEXCEPT : __data (nullptr), __size(0) {}
        ^
projects/libcxx/include/string_view:206:2: note: candidate constructor not viable: requires 2 arguments, but 1 was provided
        basic_string_view(const _CharT* __s, size_type __len)
        ^
1 error generated.

However, building with clang 3.7.0 or a later version succeeds.

In an ongoing discussion in llvm-dev, it had been mentioned that clang 3.4 is intended to be the oldest supported host compiler for llvm+clang; what's the current policy for libcxx?

I couldn't find any definite information on which compiler versions are supported for building libcxx.

Hum, it should be the same as LLVM (3.1, *cough* *cough*).

However, building with clang 3.7.0 or a later version succeeds.

I have just upgraded our buildbot from 3.6.2 to 3.9.0 a few months
ago, so it was working until very recently. I just did't know I was
the last one standing... :frowning:

In this particular case, I think we should fix libc++, not upgrade the
minimum Clang version to 3.9, as that wouldn't make sense.

In an ongoing discussion in llvm-dev, it had been mentioned that clang 3.4 is intended to be the oldest supported host compiler for llvm+clang; what's the current policy for libcxx?

Sigh... we're not doing so well in that front, as you have repeatedly
shown us... :slight_smile:

We need some higher level discussion, in addition to the "upgrade
compiler X" discussions, to make sure what do we mean by "we support
compiler X", and make sure we stand by it.

But to guarantee this, we'd have to rely on the foundation for the
hardware, as we'd need to test on Linux, Darwin and Windows, for all
three compiler versions (where appropriate).

I'll start a thread on the foundation list...

cheers,
--renato

Renato, thank you for your comments!

I couldn't find any definite information on which compiler versions are supported for building libcxx.

Hum, it should be the same as LLVM (3.1, *cough* *cough*).

However, building with clang 3.7.0 or a later version succeeds.

In this particular case, I think we should fix libc++, not upgrade the
minimum Clang version to 3.9, as that wouldn't make sense.

Eric, could you please take a look? This particular issue is due to your r284313.

For the reference, the compilation error (on clang 3.6.2 and earlier versions) is as follows

projects/libcxx/src/experimental/filesystem/path.cpp:286:14: error: no matching constructor for initialization of 'string_view_t' (aka 'basic_string_view<char>')
      return string_view_t{__pn_}.substr(0, e + 1);
             ^ ~~~~~~~
projects/libcxx/include/string_view:200:2: note: candidate constructor not viable: no known conversion from 'const string_type' (aka 'const basic_string<value_type>') to 'const
      std::__1::basic_string_view<char, std::__1::char_traits<char> > &' for 1st argument
        basic_string_view(const basic_string_view&) _NOEXCEPT = default;
        ^
projects/libcxx/include/string_view:215:2: note: candidate constructor not viable: no known conversion from 'const string_type' (aka 'const basic_string<value_type>') to 'const char *' for 1st argument
        basic_string_view(const _CharT* __s)
        ^
projects/libcxx/include/string_view:197:2: note: candidate constructor not viable: requires 0 arguments, but 1 was provided
        basic_string_view() _NOEXCEPT : __data (nullptr), __size(0) {}
        ^
projects/libcxx/include/string_view:206:2: note: candidate constructor not viable: requires 2 arguments, but 1 was provided
        basic_string_view(const _CharT* __s, size_type __len)
        ^
1 error generated.

Yep. I’ll look into this.

My 2 cents are that libc++ is special, and can’t be held to LLVM/Clang’s requirements. Implementing C++17 libraries with compilers shipped in 2014 is tricky.

However we can probably still tolerate older compilers to build the few source files the dylib is made from.

/Eric

This would make building Clang and libc++ more complicated.

Or we can keep the minimum requirement still the same (as Clang), only
compile libc++ on stage-2, and make it easy for people to do so in
CMake.

cheers,
--renato

This would make building Clang and libc++ more complicated.

And nobody wants that. I’m happy to tolerate older compilers so long as it doesn’t hurt libc++'s QoI. However libc++'s ultimate consumer is the in-tree clang it’s going to be installed beside, and the implementation should optimize for that case. Currently libc++ needs minimal C++14 support to build the C++17 libraries and hopefully that won’t change anytime soon, but it is an inevitability as new libraries get standardized which require new language features.

/Eric

Right, that's why I think that, in a future where we need to hold an
old GCC as requirement and libc++ *needs* to evolve, "it should be ok"
to mark it at a higher GCC version OR Clang OR stage-2.

But as you say, this is a last resort.

cheers,
--renato

FYI I worked around the regression in r285445 by simply changing the initialization syntax. The testsuite still runs flawlessly with 3.6 after that small fix.
I would love to add builders for older Clang versions but I only have so many free CPU cycles.

/Eric

FYI I worked around the regression in r285445 by simply changing the
initialization syntax. The testsuite still runs flawlessly with 3.6 after
that small fix.

Thanks!

I would love to add builders for older Clang versions but I only have so
many free CPU cycles.

Simon (CC'd) said he could have some spare CPUs for old builds, maybe
we should add libc++ to the list of things to test.

My libc++ bot builds so sporadically that the board is mostly idle.
Should be trivial.

cheers,
--renato

We (ARM) are also planning to setup several libc++ bots, as we have started to ship libc++ in quite a few configurations.

I just need to find some time for this. Hopefully more CPU cycles will come :slight_smile:

Cheers,

/ Asiri