Intersting powerpc64-gcc's g++ (5.2) vs. clang++ (3.7.1) (all native on
powerpc64) macro differences for default conditions:
> # more just_main.cpp
> int main(void)
> { return 0; }
> $ pkg which /usr/local/bin/powerpc64-portbld-freebsd11.0-g++
> /usr/local/bin/powerpc64-portbld-freebsd11.0-g++
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 __GX
I've submitted Bug 206588 from which the below is quoted (but is not all the
text). First I list my later comment then the beginning of the description.
> This is likely more an issue of not having a proper set of headers to use
> with powerpc64-gcc when cross compiling from other architectures,
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:
>
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 her
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:
# svnlite diff /usr/src/contrib/libc++/include/__config
Index: /usr/src/contrib/libc++/include/__config