Re: 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  wrote:


On 2016-Jan-24, at 9:20 AM, Dimitry Andric  wrote:
> 
> On 24 Jan 2016, at 12:20, Mark Millard  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=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 
 that was engaged by 2 of the mistaken disables overall (more quoted 
extractions, this time from ):

. . .
> #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:

> // 

Re: powerpc64-gcc unable to compile clang 3.8.0 from clang380-import -r294609 via buildworld

[Mark Millard]

On 2016-Jan-24, at 9:20 AM, Dimitry Andric  wrote:
> 
> On 24 Jan 2016, at 12:20, Mark Millard  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=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 
 that was engaged by 2 of the mistaken disables overall (more quoted 
extractions, this time from ):

. . .
> #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 

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

[Mark Millard]

I tried a buildworld that included building clang and lldb based on using 
powerpc64-xtoolchain-gcc/powerpc64-gcc as a cross compiler. It failed, see 
below. This might indicate a more general gcc 5.x vs. clang 3.8.0 source code 
mismatch. This was my first try. This could have been true for some time.

--- CFG.o ---
/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -isystem 
/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include 
-L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib 
--sysroot=/usr/obj/xtoolchain/powerpc.po
werpc64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ 
-I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1 
-std=gnu++11 -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/../lib/libc++ 
--sysroot=/usr
/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp 
-B/usr/local/powerpc64-freebsd/bin/  -O2 -pipe 
-I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include 
-I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm
/tools/clang/include 
-I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis
 -I. 
-I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER 
-fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd11.0\" 
-DLLVM_HOST_TRIPLE=\"powerpc64
-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" -MD -MP -MF.depend.CFG.o -MTCFG.o 
-fstack-protector-strong -Wno-error=unused-function -Wno-error=enum-compare 
-Wno-error=logical-not-parentheses -Wno-error=bool-compare -Wno-
error=uninitialized -Wno-error=array-bounds -Wno-error=clobbered 
-Wno-error=cast-align -Wno-error=extra -Wno-error=attributes -Wno-error=inline 
-Wno-error=unused-but-set-variable -Wno-error=unused-value -Wno-error=strict
-aliasing -Wno-error=address  -std=c++11 -fno-exceptions -fno-rtti  -c 
/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/CFG.cpp
 -o CFG.o
. . .
--- all_subdir_libclanganalysis ---
/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/CFG.cpp:
 In member function 'std::__1::unique_ptr 
{anonymous}::CFGBuilder::buildCFG(const clang::Decl*, clang::Stmt*)':
/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/CFG.cpp:1046:45:
 error: no matching function for call to 
'reverse(clang::CXXConstructorDecl::init_const_range)'
 for (auto *I : llvm::reverse(CD->inits())) {
 ^

(not the only error reported for CFG.cpp’s compile, I just listed the first).

I do not know if the -std=gnu++11 that is automatically used is causing 
variations in the language definition in use or not.



I do this sort of thing with 11.0-CURRENT now and have been for a long time, 
including building clang 3.7.1 and its lldb via powerpc64-gcc in more recent 
times. But powerpc64-gcc has historically rejected the clang extras so I’ve 
used WITHOUT_CLANG_EXTRAS= historically.



Some context notes:

Empty make.conf via __MAKE_CONF use.

scr.conf:
(actually: used via SRC_ENV_CONF=)

TO_TYPE=powerpc64
TOOLS_TO_TYPE=${TO_TYPE}
FROM_TYPE=amd64
TOOLS_FROM_TYPE=x86_64
VERSION_CONTEXT=11.0
#
KERNCONF=GENERIC64vtsc-NODEBUG
TARGET=powerpc
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITHOUT_CROSS_COMPILER=
#
# 1 thing that fails to build if attempted via gcc variants:
WITHOUT_CLANG_EXTRAS=
#
WITH_FAST_DEPEND=
WITH_LIBCPLUSPLUS=
WITH_LIB32=
WITH_BOOT=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_LLDB=
#
WITHOUT_GCC=
WITHOUT_GNUCXX=
#
NO_WERROR=
MALLOC_PRODUCTION=
#CFLAGS+= -DELF_VERBOSE
#
WITH_DEBUG=
WITH_DEBUG_FILES=
#
# TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related bintutils...
#
CROSS_TOOLCHAIN=${TO_TYPE}-gcc
X_COMPILER_TYPE=gcc
CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
#
.if ${.MAKE.LEVEL} == 0
XCC=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gcc
XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g++
XCPP=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-cpp
.export XCC
.export XCXX
.export XCPP
XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
#NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
.export XAS
.export XAR
.export XLD
.export XNM
.export XOBJCOPY
.export XOBJDUMP
.export XRANLIB
.export XSIZE
.export XSTRINGS
.endif
#
# From clang (via system)...
#
.if ${.MAKE.LEVEL} == 0
CC=/usr/bin/clang 

Re: powerpc64-gcc unable to compile clang 3.8.0 from clang380-import -r294609 via buildworld

[Dimitry Andric]

On 23 Jan 2016, at 12:25, Mark Millard  wrote:
> 
> I tried a buildworld that included building clang and lldb based on using 
> powerpc64-xtoolchain-gcc/powerpc64-gcc as a cross compiler. It failed, see 
> below. This might indicate a more general gcc 5.x vs. clang 3.8.0 source code 
> mismatch. This was my first try. This could have been true for some time.
> 
> --- CFG.o ---
> /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -isystem 
> /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include 
> -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib 
> --sysroot=/usr/obj/xtoolchain/powerpc.po
> werpc64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ 
> -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1 
> -std=gnu++11 
> -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/../lib/libc++ 
> --sysroot=/usr
> /obj/xtoolchain/powerpc.powerpc64/usr/src/tmp 
> -B/usr/local/powerpc64-freebsd/bin/  -O2 -pipe 
> -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include 
> -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm
> /tools/clang/include 
> -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis
>  -I. 
> -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/../../lib/clang/include
>  -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
> -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER 
> -fno-strict-aliasing 
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd11.0\" 
> -DLLVM_HOST_TRIPLE=\"powerpc64
> -unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" -MD -MP -MF.depend.CFG.o 
> -MTCFG.o -fstack-protector-strong -Wno-error=unused-function 
> -Wno-error=enum-compare -Wno-error=logical-not-parentheses 
> -Wno-error=bool-compare -Wno-
> error=uninitialized -Wno-error=array-bounds -Wno-error=clobbered 
> -Wno-error=cast-align -Wno-error=extra -Wno-error=attributes 
> -Wno-error=inline -Wno-error=unused-but-set-variable -Wno-error=unused-value 
> -Wno-error=strict
> -aliasing -Wno-error=address  -std=c++11 -fno-exceptions -fno-rtti  -c 
> /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/CFG.cpp
>  -o CFG.o
> . . .
> --- all_subdir_libclanganalysis ---
> /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/CFG.cpp:
>  In member function 'std::__1::unique_ptr 
> {anonymous}::CFGBuilder::buildCFG(const clang::Decl*, clang::Stmt*)':
> /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/CFG.cpp:1046:45:
>  error: no matching function for call to 
> 'reverse(clang::CXXConstructorDecl::init_const_range)'
> for (auto *I : llvm::reverse(CD->inits())) {
> ^

I just tried building clang 3.8.0 with gcc 5.3.0, but that went fine.
However, by default gcc uses its own copy of libstdc++.  The above error
is most likely something caused by libc++ and gcc not playing well
together.

This kind of error is always hard to report upstream, since the gcc
maintainers obviously do not care that much about libc++, while the
libc++ maintainers do not care that much about gcc. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: powerpc64-gcc unable to compile clang 3.8.0 from clang380-import -r294609 via buildworld

[Mark Millard]

I found a (the?) overall smoking gun: for powerpc64-gcc FreeBSD's 
/projects/clang380-import/contrib/libc++/include/__config is doing (for 
example):

#define _LIBCPP_HAS_NO_RVALUE_REFERENCES

(and other out of date classifications) for gcc5 vintages, and possibly for 
gcc49 and others as well.

This in turn means that other parts of libc++ are not providing modern 
definitions that modern enough gcc5 variations handle fine. Instead libc++ 
provides old definitions that are incorrect/incomplete for c++11 and later 
(despite use of -std=c++11 on the command line).

clang++ gets the modern definitions from libc++.

So: Not a gcc problem, a libc++ problem.


In the code that got the initial error report that I showed 
/projects/clang380-import/contrib/libc++/include/__config was using old 
definitions of std::begin(. . .) and std::end(. . .) for powerpc64-gcc and when 
the modern definitions are used instead under powerpc64-gcc the matching error 
report disappears.


Part of this may be that __config is still always expecting for g++ that 
__GXX_EXPERIMENTAL_CXX0X__ is defined if nearly any of the modern c++11 or 
later features exist at all. At this point various things are not experimental 
any more and -std=c++11 features likely are not considered experimental any 
more in more recent gcc5 and later vintages.

This __GXX_EXPERIMENTAL_CXX0X__ use is still true of __config at llvm's 
/libcxx/tags/RELEASE_380/rc1/include/__config and at llvm's 
/libcxx/trunk/include/__config too (head of trunk for the file).


Looking at the most recent content of FreeBSD's 
/projects/clang380-import/contrib/libc++/include/__config shows:

. . .
#elif defined(__GNUC__)
. . .
. . .
// GCC 5 will support variable templates
#define _LIBCPP_HAS_NO_VARIABLE_TEMPLATES
. . .
#ifndef __GXX_EXPERIMENTAL_CXX0X__
. . .
#define _LIBCPP_HAS_NO_RVALUE_REFERENCES
. . .
#else  // __GXX_EXPERIMENTAL_CXX0X__
. . .
#if _GNUC_VER < 403
#define _LIBCPP_HAS_NO_RVALUE_REFERENCES
#endif
. . .

_LIBCPP_HAS_NO_RVALUE_REFERENCES being defined in turn causes 
/projects/clang380-import/contrib/libc++/include/iterator to define things like 
std::begin(. . .) in an old way, such as the following that was involved in the 
initial error report that I got:

> #else  // !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && 
> !defined(_LIBCPP_HAS_NO_TRAILING_RETURN)
> 
> template 
> inline _LIBCPP_INLINE_VISIBILITY
> typename _Cp::iterator
> begin(_Cp& __c)
> {
> return __c.begin();
> }
> 
> template 
> inline _LIBCPP_INLINE_VISIBILITY
> typename _Cp::const_iterator
> begin(const _Cp& __c)
> {
> return __c.begin();
> }
> 
> template 
> inline _LIBCPP_INLINE_VISIBILITY
> typename _Cp::iterator
> end(_Cp& __c)
> {
> return __c.end();
> }
> 
> template 
> inline _LIBCPP_INLINE_VISIBILITY
> typename _Cp::const_iterator
> end(const _Cp& __c)
> {
> return __c.end();
> }


Manually forced replacement with modern source:

> template 
> inline _LIBCPP_INLINE_VISIBILITY
> auto
> begin(_Cp& __c) -> decltype(__c.begin())
> {
> return __c.begin();
> }
> 
> template 
> inline _LIBCPP_INLINE_VISIBILITY
> auto
> begin(const _Cp& __c) -> decltype(__c.begin())
> {
> return __c.begin();
> }
> 
> template 
> inline _LIBCPP_INLINE_VISIBILITY
> auto
> end(_Cp& __c) -> decltype(__c.end())
> {
> return __c.end();
> }
> 
> template 
> inline _LIBCPP_INLINE_VISIBILITY
> auto
> end(const _Cp& __c) -> decltype(__c.end())
> {
> return __c.end();
> }

eliminated the specific initial error report. (It is not a sufficient 
workaround to build clang as far as I know.)

The following code extracted from libc++ and simplified from the llvm code that 
got the initial error that I showed can be used to experiment with the 
definitions of std::begin(. . .) and std:end(. . .) for powerpc64-gcc vs. 
clang++ via commands like:

> /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -std=c++11 
> -I/usr/include/c++/v1/ func.cpp

vs.

> clang++ -std=c++11 -stdlib=libc++ func.cpp


with func.cpp being . . .
(llvm's head-of-trunk iterator still has the same #if . . . #else . . . #endif 
structure)

> #include <__config>
> 
> _LIBCPP_BEGIN_NAMESPACE_STD
> 
> #if !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && 
> !defined(_LIBCPP_HAS_NO_TRAILING_RETURN)
> 
> template 
> inline _LIBCPP_INLINE_VISIBILITY
> auto
> begin(_Cp& __c) -> decltype(__c.begin())
> {
> return __c.begin();
> }
> 
> template 
> inline _LIBCPP_INLINE_VISIBILITY
> auto
> begin(const _Cp& __c) -> decltype(__c.begin())
> {
> return __c.begin();
> }
> 
> template 
> inline _LIBCPP_INLINE_VISIBILITY
> auto
> end(_Cp& __c) -> decltype(__c.end())
> {
> return __c.end();
> }
> 
> template 
> inline _LIBCPP_INLINE_VISIBILITY
> auto
> end(const _Cp& __c) -> decltype(__c.end())
> {
> return __c.end();
> }
> 
> #else  // !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && 
> !defined(_LIBCPP_HAS_NO_TRAILING_RETURN)
> 
> template 
> inline _LIBCPP_INLINE_VISIBILITY
> typename _Cp::iterator
> begin(_Cp& __c)
> {
>