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