Re: CXXSTD=c++11

[Dimitry Andric]

On 25 Mar 2016, at 00:18, Bryan Drewery  wrote:
> 
> On 3/24/2016 4:16 PM, Dimitry Andric wrote:
>> On 24 Mar 2016, at 23:54, Dimitry Andric  wrote:
>>> 
>>> On 24 Mar 2016, at 23:51, Bryan Drewery  wrote:
>> ...
 It fails without -std=c++11 (there's more discussion in that link and in
 PR 205453).
>>> 
>>> Yeah, I also commented on PR 205453 in the past, but I still don't
>>> understand where the external gcc gets its _Static_assert macro from.
>>> Or whether it gets it at all.  Maybe we should place a hack for this in
>>> sys/cdefs.h?  We shouldn't litter contrib code with #ifdef GCC_VERSION
>>> blocks.
>> 
>> Hm, hacking around in cdefs.h also doesn't really help, because gcc
>> refuses to recognize either _Static_assert or static_assert when it's
>> not in C++11 mode.  Reading back https://reviews.freebsd.org/D1390, I
>> see that I originally wanted to avoid building libcxxrt with -std=c++11.
>> This was so you could even build it with gcc 4.2.1 from base.
>> 
>> However, it really doesn't make much sense to do so, and upstream
>> libcxxrt simply uses static_assert directly, and requires -std=c++11.  I
>> will update the libcxxrt build to do so, probably tomorrow.
>> 
> 
> Sounds good.

Done in r297299 [1].  I also imported libc++ r255683 [2], which should
fix llvm-cov compilation with g++, in r297322 [3].

-Dimitry

[1] https://svnweb.freebsd.org/changeset/base/297299
[2] http://reviews.llvm.org/rL255683
[3] https://svnweb.freebsd.org/changeset/base/297322



signature.asc
Description: Message signed with OpenPGP using GPGMail

CXXSTD=c++11

[Mark Millard]

[Just a few notes related to some points in the exchange.]

powerpc and powerpc64 are in the same boat as mips and sparc for clang's 
overall status: clang does not work yet, independent of any FreeBSD issues that 
might exist if clang's code generation was okay. (See 
https://llvm.org/bugs/show_bug.cgi?id=25780 and what it "depends on".)

I've been able to buildworld using WITH_LIB32= via 
powerpc64-xtoolchain-gcc/powerpc64-gcc with the libcxxrt _Static_assert 
disabled but what was built has never worked because of some of the code in the 
crtbeginS.o produced. (See 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206123 .)

powerpc64-xtoolchain-gcc/powerpc64-gcc as it is currently built when used on a 
powerpc64 (self hosting "cross builds" for buildworld) historically looks in 
and prefers /usr/local/include/ include files so I first rename files that 
caused me problems, for example:

> # ls /usr/local/include/renamed_*
> /usr/local/include/renamed_dwarf.h/usr/local/include/renamed_iconv.h  
> /usr/local/include/renamed_libdwarf.h

I do not know if the -isystem change(s) will improve this to prefer the likes 
of (in my context) 
/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1 and/or 
/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include or not. It is too 
bad that powerpc64-gcc automatically looks in /usr/local/include .

Direct use of the live-system's /usr/include/c++/v1 area would be the wrong 
place if that code had updates. As I understand things, ${WORLDTMP} use is 
appropriate in forming the include directory paths (in my context: 
/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp prefixes).


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

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: CXXSTD=c++11

[Bryan Drewery]

On 3/24/2016 4:16 PM, Dimitry Andric wrote:
> On 24 Mar 2016, at 23:54, Dimitry Andric  wrote:
>>
>> On 24 Mar 2016, at 23:51, Bryan Drewery  wrote:
> ...
>>> It fails without -std=c++11 (there's more discussion in that link and in
>>> PR 205453).
>>
>> Yeah, I also commented on PR 205453 in the past, but I still don't
>> understand where the external gcc gets its _Static_assert macro from.
>> Or whether it gets it at all.  Maybe we should place a hack for this in
>> sys/cdefs.h?  We shouldn't litter contrib code with #ifdef GCC_VERSION
>> blocks.
> 
> Hm, hacking around in cdefs.h also doesn't really help, because gcc
> refuses to recognize either _Static_assert or static_assert when it's
> not in C++11 mode.  Reading back https://reviews.freebsd.org/D1390, I
> see that I originally wanted to avoid building libcxxrt with -std=c++11.
> This was so you could even build it with gcc 4.2.1 from base.
> 
> However, it really doesn't make much sense to do so, and upstream
> libcxxrt simply uses static_assert directly, and requires -std=c++11.  I
> will update the libcxxrt build to do so, probably tomorrow.
> 

Sounds good.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: CXXSTD=c++11

[Dimitry Andric]

On 24 Mar 2016, at 23:54, Dimitry Andric  wrote:
> 
> On 24 Mar 2016, at 23:51, Bryan Drewery  wrote:
...
>> It fails without -std=c++11 (there's more discussion in that link and in
>> PR 205453).
> 
> Yeah, I also commented on PR 205453 in the past, but I still don't
> understand where the external gcc gets its _Static_assert macro from.
> Or whether it gets it at all.  Maybe we should place a hack for this in
> sys/cdefs.h?  We shouldn't litter contrib code with #ifdef GCC_VERSION
> blocks.

Hm, hacking around in cdefs.h also doesn't really help, because gcc
refuses to recognize either _Static_assert or static_assert when it's
not in C++11 mode.  Reading back https://reviews.freebsd.org/D1390, I
see that I originally wanted to avoid building libcxxrt with -std=c++11.
This was so you could even build it with gcc 4.2.1 from base.

However, it really doesn't make much sense to do so, and upstream
libcxxrt simply uses static_assert directly, and requires -std=c++11.  I
will update the libcxxrt build to do so, probably tomorrow.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: CXXSTD=c++11

[Bryan Drewery]

On 3/24/2016 4:13 PM, Bryan Drewery wrote:
> Well _Static_assert is C++11 and static_assert is C11.

Yes I have it backwards, same point though.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: CXXSTD=c++11

[Bryan Drewery]

On 3/24/2016 3:54 PM, Dimitry Andric wrote:
> On 24 Mar 2016, at 23:51, Bryan Drewery  wrote:
>>
>> On 3/24/2016 3:45 PM, Bryan Drewery wrote:
>>> On 3/24/2016 3:44 PM, Dimitry Andric wrote:
 On 24 Mar 2016, at 23:36, Bryan Drewery  wrote:
>
> Is there any problem with forcing -std=c++11 for all CXX/LIB_CXX builds
> now?  We do this when using an external GCC since it doesn't default to
> the c++11 standard quite yet.  As far as I understand, we require c++11
> to build clang/libc++.

 Yes, but it already passes -std=c++11 in the correct places, as far as I
 know.  E.g. during the clang and libc++ builds.


> It seems to be the problem at
> https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-October/001757.html
> which I've fixed in an upcoming commit to properly pass -std=c++11 to
> the lib32 build in CXXFLAGS.

 Hm, is this occuring during the build of libcxxrt, or of libc++?  If it
 is the former, then it seems that the system headers don't properly
 declare _Static_assert() in that case.  I have no clue as to why, though
 maybe it's picking something up from gcc's famously "fixed" standard
 headers?

>>>
>>> libcxxrt.
>>>
>>> My fix also includes passing the proper -isystem =/usr/include/c++/v1 path.
>>>
>>> I'll try without the -std change.
>>>
>>>
>>
>> It fails without -std=c++11 (there's more discussion in that link and in
>> PR 205453).
> 
> Yeah, I also commented on PR 205453 in the past, but I still don't
> understand where the external gcc gets its _Static_assert macro from.
> Or whether it gets it at all.  Maybe we should place a hack for this in
> sys/cdefs.h?  We shouldn't litter contrib code with #ifdef GCC_VERSION
> blocks.
> 

Well _Static_assert is C++11 and static_assert is C11. These files are
being built by GCC as C++03, so neither is presumably available without
raising the standard.

Shouldn't this be using static_assert with a CXXFLAGS+=-std=c++11 or
CSTD=c11 ?


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: CXXSTD=c++11

[Dimitry Andric]

On 24 Mar 2016, at 23:51, Bryan Drewery  wrote:
> 
> On 3/24/2016 3:45 PM, Bryan Drewery wrote:
>> On 3/24/2016 3:44 PM, Dimitry Andric wrote:
>>> On 24 Mar 2016, at 23:36, Bryan Drewery  wrote:
 
 Is there any problem with forcing -std=c++11 for all CXX/LIB_CXX builds
 now?  We do this when using an external GCC since it doesn't default to
 the c++11 standard quite yet.  As far as I understand, we require c++11
 to build clang/libc++.
>>> 
>>> Yes, but it already passes -std=c++11 in the correct places, as far as I
>>> know.  E.g. during the clang and libc++ builds.
>>> 
>>> 
 It seems to be the problem at
 https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-October/001757.html
 which I've fixed in an upcoming commit to properly pass -std=c++11 to
 the lib32 build in CXXFLAGS.
>>> 
>>> Hm, is this occuring during the build of libcxxrt, or of libc++?  If it
>>> is the former, then it seems that the system headers don't properly
>>> declare _Static_assert() in that case.  I have no clue as to why, though
>>> maybe it's picking something up from gcc's famously "fixed" standard
>>> headers?
>>> 
>> 
>> libcxxrt.
>> 
>> My fix also includes passing the proper -isystem =/usr/include/c++/v1 path.
>> 
>> I'll try without the -std change.
>> 
>> 
> 
> It fails without -std=c++11 (there's more discussion in that link and in
> PR 205453).

Yeah, I also commented on PR 205453 in the past, but I still don't
understand where the external gcc gets its _Static_assert macro from.
Or whether it gets it at all.  Maybe we should place a hack for this in
sys/cdefs.h?  We shouldn't litter contrib code with #ifdef GCC_VERSION
blocks.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: CXXSTD=c++11

[Bryan Drewery]

On 3/24/2016 3:45 PM, Bryan Drewery wrote:
> On 3/24/2016 3:44 PM, Dimitry Andric wrote:
>> On 24 Mar 2016, at 23:36, Bryan Drewery  wrote:
>>>
>>> Is there any problem with forcing -std=c++11 for all CXX/LIB_CXX builds
>>> now?  We do this when using an external GCC since it doesn't default to
>>> the c++11 standard quite yet.  As far as I understand, we require c++11
>>> to build clang/libc++.
>>
>> Yes, but it already passes -std=c++11 in the correct places, as far as I
>> know.  E.g. during the clang and libc++ builds.
>>
>>
>>> It seems to be the problem at
>>> https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-October/001757.html
>>> which I've fixed in an upcoming commit to properly pass -std=c++11 to
>>> the lib32 build in CXXFLAGS.
>>
>> Hm, is this occuring during the build of libcxxrt, or of libc++?  If it
>> is the former, then it seems that the system headers don't properly
>> declare _Static_assert() in that case.  I have no clue as to why, though
>> maybe it's picking something up from gcc's famously "fixed" standard
>> headers?
>>
> 
> libcxxrt.
> 
> My fix also includes passing the proper -isystem =/usr/include/c++/v1 path.
> 
> I'll try without the -std change.
> 
> 

It fails without -std=c++11 (there's more discussion in that link and in
PR 205453).

> /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -m32 -DCOMPAT_32BIT 
> -mcpu=powerpc  --sysroot=/usr/obj/powerpc.powerpc64/root/git/freebsd/lib32  
> -L/usr/obj/powerpc.powerpc64/root/git/freebsd/lib32/usr/lib32 
> -B/usr/obj/powerpc.powerpc64/root/git/freebsd/lib32/usr/lib32 -isystem 
> /usr/obj/powerpc.powerpc64/root/git/freebsd/lib32/usr/include -isystem 
> /usr/obj/powerpc.powerpc64/root/git/freebsd/lib32/usr/include/c++/v1  
> -L/usr/obj/powerpc.powerpc64/root/git/freebsd/world32//root/git/freebsd/lib/libc++
>  -pg  -O2 -pipe -I/root/git/freebsd/lib/libcxxrt/../../contrib/libcxxrt -MD 
> -MF.depend.guard.po -MTguard.po -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=addre
ss   -c /root/git/freebsd/lib/libcxxrt/../../contrib/libcxxrt/guard.cc -o 
guard.po
> --- guard.o ---
> /root/git/freebsd/lib/libcxxrt/../../contrib/libcxxrt/guard.cc:104:15: error: 
> expected constructor, destructor, or type conversion before '(' token
>  _Static_assert(sizeof(guard_t) == sizeof(uint64_t), "");
>^
> --- libelftc_dem_gnu3.So ---
> --- guard.o ---
> *** [guard.o] Error code 1
> 
> make[4]: stopped in /root/git/freebsd/lib/libcxxrt


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: CXXSTD=c++11

[Bryan Drewery]

On 3/24/2016 3:44 PM, Dimitry Andric wrote:
> On 24 Mar 2016, at 23:36, Bryan Drewery  wrote:
>>
>> Is there any problem with forcing -std=c++11 for all CXX/LIB_CXX builds
>> now?  We do this when using an external GCC since it doesn't default to
>> the c++11 standard quite yet.  As far as I understand, we require c++11
>> to build clang/libc++.
> 
> Yes, but it already passes -std=c++11 in the correct places, as far as I
> know.  E.g. during the clang and libc++ builds.
> 
> 
>> It seems to be the problem at
>> https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-October/001757.html
>> which I've fixed in an upcoming commit to properly pass -std=c++11 to
>> the lib32 build in CXXFLAGS.
> 
> Hm, is this occuring during the build of libcxxrt, or of libc++?  If it
> is the former, then it seems that the system headers don't properly
> declare _Static_assert() in that case.  I have no clue as to why, though
> maybe it's picking something up from gcc's famously "fixed" standard
> headers?
> 

libcxxrt.

My fix also includes passing the proper -isystem =/usr/include/c++/v1 path.

I'll try without the -std change.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: CXXSTD=c++11

[Dimitry Andric]

On 24 Mar 2016, at 23:36, Bryan Drewery  wrote:
> 
> Is there any problem with forcing -std=c++11 for all CXX/LIB_CXX builds
> now?  We do this when using an external GCC since it doesn't default to
> the c++11 standard quite yet.  As far as I understand, we require c++11
> to build clang/libc++.

Yes, but it already passes -std=c++11 in the correct places, as far as I
know.  E.g. during the clang and libc++ builds.


> It seems to be the problem at
> https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-October/001757.html
> which I've fixed in an upcoming commit to properly pass -std=c++11 to
> the lib32 build in CXXFLAGS.

Hm, is this occuring during the build of libcxxrt, or of libc++?  If it
is the former, then it seems that the system headers don't properly
declare _Static_assert() in that case.  I have no clue as to why, though
maybe it's picking something up from gcc's famously "fixed" standard
headers?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: CXXSTD=c++11

[Warner Losh]

> On Mar 24, 2016, at 4:36 PM, Bryan Drewery  wrote:
> 
> Is there any problem with forcing -std=c++11 for all CXX/LIB_CXX builds
> now?  We do this when using an external GCC since it doesn't default to
> the c++11 standard quite yet.  As far as I understand, we require c++11
> to build clang/libc++.
> 
> It seems to be the problem at
> https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-October/001757.html
> which I've fixed in an upcoming commit to properly pass -std=c++11 to
> the lib32 build in CXXFLAGS.

Wouldn’t that break the spark and mips builds if we did it always? They are the
last stragglers to not have a working, fully vetted clang in the tree.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

CXXSTD=c++11

[Bryan Drewery]

Is there any problem with forcing -std=c++11 for all CXX/LIB_CXX builds
now?  We do this when using an external GCC since it doesn't default to
the c++11 standard quite yet.  As far as I understand, we require c++11
to build clang/libc++.

It seems to be the problem at
https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-October/001757.html
which I've fixed in an upcoming commit to properly pass -std=c++11 to
the lib32 build in CXXFLAGS.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature