powerpc64-gcc unable to compile clang 3.8.0 from clang380-import -r294609 via buildworld [correction]

[Mark Millard]

Looks like I screwed up by thinking that one of my tests had neither of _LIBCPP_HAS_NO_TRAILING_RETURN nor _LIBCPP_HAS_NO_RVALUE_REFERENCES defined when in fact _LIBCPP_HAS_NO_TRAILING_RETURN was still defined (making _LIBCPP_HAS_NO_RVALUE_REFERENCES irrelevant).

Other forms of checking if __GXX_EXPERIMENTAL_CXX0X__ is defined or not when -std=c++11 is used have all shown that it is defined for the g++ vintages in question. (SOME_GCC_CMD -std=c++11 -dM -E - < /dev/null can not be used: an actual source code file name is required on the command line to get an actual C++ compile even when -std=c++11 is specified. The - < /dev/null use reverts to a C compile with a message about doing so.)

So I'm running a buildworld to cross-check but I now expect that you [Dimitry] are correct that my

> -#ifndef __GXX_EXPERIMENTAL_CXX0X__
> +#if !defined(__GXX_EXPERIMENTAL_CXX0X__) && __cplusplus < 201103L

was not and is not needed.

===
Mark Millard
markmi at dsl-only.net

On 2016-Jan-24, at 12:39 PM, Mark Millard <markmi at dsl-only.net> wrote:


On 2016-Jan-24, at 9:20 AM, Dimitry Andric <dim at FreeBSD.org> wrote:
> 
> On 24 Jan 2016, at 12:20, Mark Millard <markmi at dsl-only.net> wrote:
>> 
>> My current trial powerpc64-gcc based buildworld is well past where it stopped before (in a clang 3.8.0 part of the build). What I changed in libc++ was just a little of __config:
> 
> It appears upstream has done approximately the same thing here:
> http://llvm.org/viewvc/llvm-project?view=revision&revision=255585
> 
> 
>> # svnlite diff /usr/src/contrib/libc++/include/__config
>> Index: /usr/src/contrib/libc++/include/__config
>> ===================================================================
>> --- /usr/src/contrib/libc++/include/__config	(revision 294609)
>> +++ /usr/src/contrib/libc++/include/__config	(working copy)
>> @@ -432,13 +432,15 @@
>> // No version of GCC supports relaxed constexpr rules
>> #define _LIBCPP_HAS_NO_CXX14_CONSTEXPR
>> // GCC 5 will support variable templates
>> +#if !defined(__cpp_variable_templates) || __cpp_variable_templates < 201304L
>> #define _LIBCPP_HAS_NO_VARIABLE_TEMPLATES
>> +#endif
>> 
>> #define _NOEXCEPT throw()
>> #define _NOEXCEPT_(x)
>> #define _NOEXCEPT_OR_FALSE(x) false
>> 
>> -#ifndef __GXX_EXPERIMENTAL_CXX0X__
>> +#if !defined(__GXX_EXPERIMENTAL_CXX0X__) && __cplusplus < 201103L
> 
> Except for this change.  Why was this needed?

-r255585 (and later) upstream still has (quoted extractions from file showing more context):

> #elif defined(__GNUC__)
. . .
> #define _NOEXCEPT throw()
> #define _NOEXCEPT_(x)
> #define _NOEXCEPT_OR_FALSE(x) false
> 
> #ifndef __GXX_EXPERIMENTAL_CXX0X__
> 
> #define _LIBCPP_HAS_NO_ADVANCED_SFINAE
> #define _LIBCPP_HAS_NO_DECLTYPE
> #define _LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS
> #define _LIBCPP_HAS_NO_DELETED_FUNCTIONS
> #define _LIBCPP_HAS_NO_NULLPTR
> #define _LIBCPP_HAS_NO_STATIC_ASSERT
> #define _LIBCPP_HAS_NO_UNICODE_CHARS
> #define _LIBCPP_HAS_NO_VARIADICS
> #define _LIBCPP_HAS_NO_RVALUE_REFERENCES
> #define _LIBCPP_HAS_NO_ALWAYS_INLINE_VARIADICS
> #define _LIBCPP_HAS_NO_STRONG_ENUMS
> 
> #else  // __GXX_EXPERIMENTAL_CXX0X__
. . .

In modern times for -std=c++11 this turns off the 11 or so features by defining the 11 or so macros. This is because -std=c++11  in powerpc64-gcc is no longer classfied as experimental (experimental before 5.1, not 5.1 and later if I what I read is correct). Those disabled things are no longer experimental and __GXX_EXPERIMENTAL_CXX0X__ no longer determines their status in sufficiently modern g++'s.

And it appears that clang/llvm is gradually doing things that add more dependence on having enabled c++11 features, such as now getting the error that I originally showed.

Without such a __config change powerpc64-gcc will not compile the 3.8.0 source: I tried before changing it. (_LIBCPP_HAS_NO_TRAILING_RETURN also needs to not be defined to avoid the specific error that I showed. It is not just _LIBCPP_HAS_NO_RVALUE_REFERENCES that matters.)

I picked the __cplusplus version check based on using boost's long-established version check (1.57.0-1.60.0 of boost) but using 201103L makes sense from the language definition point of view as well.

The specific error that I originally showed traced back to std::begin(. . .) and std::end(. . .) getting old definitions because of the conditional logic in <iterator> that was engaged by 2 of the mistaken disables overall (more quoted extractions, this time from <iterator>):

. . .
> #if !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && !defined(_LIBCPP_HAS_NO_TRAILING_RETURN)

. . . Modern std::begin and std::end definitions (and more) . . .

> #else  // !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && !defined(_LIBCPP_HAS_NO_TRAILING_RETURN)

. . . Old std::begin and std::end definitions . . .

> #endif  // !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && !defined(_LIBCPP_HAS_NO_TRAILING_RETURN)
. . .


Other notes:

It looks like -r255585 upstream also added to the logic for _LIBCPP_HAS_NO_CONSTEXPR and has:

> // constexpr was added to GCC in 4.6.
> #if _GNUC_VER < 406
> #define _LIBCPP_HAS_NO_CONSTEXPR
> // Can only use constexpr in c++11 mode.
> #elif !defined(__GXX_EXPERIMENTAL_CXX0X__) && __cplusplus < 201103L
> #define _LIBCPP_HAS_NO_CONSTEXPR
> #endif

that I did not that way. There are also versions:

-r257707 2016-Jan-13
-r257629 2016-Jan-13 (marked as "Update version to 3.9")
-r257422 2016-Jan-11
-r257368 2016-Jan-11
-r256652 2015-Dec-30
-r256325 2015-Dec-23
-r255868 2015-Dec-15
-r255683 2015-Dec-15
-r255585 2015-Dec-14 (the one that you identified)

But I did not try to pick a point from this history of changes at all and so may have missed other things that would be appropriate beyond the issue that I was trying to address.


I may well be the only one that cares if powerpc64-gcc (or analogous ???-gcc's) can buildworld for clang380-import before it is merged into 11.0-CURRENT. Since I've been able to rebuild (non-LIB32) I'm not stuck if you leave things as they are for now.

If __config is not changed now, I'll try to be a cross check on remembering the issue later so that 11.0-CURRENT can continue to build (non-LIB32) with powerpc64-gcc. (I do not have any hardware context for other ???-gcc xtoolchain use but all should track powerpc64-gcc on the issue as far as I know.)

===
Mark Millard
markmi at dsl-only.net