Re: head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing)

2017-06-29 Thread Mark Millard 
[I found where the tools are listed that are copied,
the list that is missing head.]

On 2017-Jun-29, at 3:33 PM, Mark Millard  wrote:

> [This is a clang targetting powerpc64 context from my
> experimentation efforts, not the normal gcc 4.2.1 context
> for powerpc64.]
> 
> I break out the PATH into lines below to make it easier to scan.
> See the later "sh: head: not found" line and the even later ls
> of the directory with the x86-64 program directory in use: no
> "head" is present to find.
> 
> --- install32 ---
> cd /usr/src/lib; MACHINE=powerpc MACHINE_ARCH=powerpc 
> MAKEOBJDIRPREFIX=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/world32
> PATH=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/legacy/usr/sbin
> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/legacy/usr/bin
> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/legacy/bin
> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/usr/sbin
> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/usr/bin
> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/legacy/usr/sbin
> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/legacy/usr/bin
> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/legacy/bin
> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/usr/sbin
> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/usr/bin
> :/tmp/install.7ljKosWa
> SYSROOT=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32
>  LIBDIR=/usr/lib32 SHLIBDIR=/usr/lib32 DTRACE="dtrace" make 
> LD="/usr/local/powerpc64-freebsd/bin/ld -m elf32ppc_fbsd" 
> OBJCOPY="/usr/local/powerpc64-freebsd/bin/objcopy" 
> NM="/usr/local/powerpc64-freebsd/bin/nm" -DCOMPAT_32BIT CC="cc -target 
> powerpc64-unknown-freebsd12.0 
> --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp
>  -B/usr/local/powerpc64-freebsd/bin/ -DCOMPAT_32BIT -mcpu=powerpc -m32  
> -L/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib32
>   
> --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32
>   -B/usr/local/powerpc64-freebsd/bin/ 
> -B/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib32"
>  CXX="c++  -target powerpc64-unknown-freebsd12.0 
> --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp
>  -B/usr/local/powerpc64-freebsd/bin/  -DCOMPAT_32BIT -mcpu=powerpc -m32  -
 L/
> usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib32
>   
> --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32
>   -B/usr/local/powerpc64-freebsd/bin/ 
> -B/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib32"
>  CPP="cpp -target powerpc64-unknown-freebsd12.0 
> --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp
>  -B/usr/local/powerpc64-freebsd/bin/ -DCOMPAT_32BIT -mcpu=powerpc -m32  
> -L/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib32
>   
> --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32
>   -B/usr/local/powerpc64-freebsd/bin/ 
> -B/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib32"
>  -DNO_CPU_CFLAGS MK_CTF=no -DNO_LINT MK_TESTS=no MK_MAN=no MK_HTML=no  
> MK_TOOLCHAIN=no   -DLIBRARIES_ONLY install
> sh: head: not found
> make[4]: "/usr/src/share/mk/bsd.linker.mk" line 47: Unable to determine 
> linker type from XLD=/usr/local/powerpc64-freebsd/bin/ld
> *** [install32] Error code 1
> 
> # ls -lT /tmp/install.7ljKosWa/
> total 6151
> -r-xr-xr-x1 root  wheel12592 Jun 29 14:02:46 2017 [
> -r-xr-xr-x1 root  wheel   207320 Jun 29 14:02:46 2017 awk
> -r-xr-xr-x1 root  wheel 8456 Jun 29 14:02:46 2017 cap_mkdb
> -r-xr-xr-x1 root  wheel13272 Jun 29 14:02:46 2017 cat
> . . .
> -r-xr-xr-x1 root  wheel57632 Jun 29 14:02:46 2017 find
> -r-xr-xr-x1 root  wheel99064 Jun 29 14:02:46 2017 grep
> -r-xr-xr-x1 root  wheel13360 Jun 29 14:02:46 2017 id
> . . .
> 
> So there is no "head" to find. Below uses "find" instead
> to confirm the x86-64 ELF status:
> 
> # file /tmp/install.7ljKosWa/find
> /tmp/install.7ljKosWa/find: ELF 64-bit LSB executable, x86-64, version 1 
> (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 
> 12.0 (1200036), FreeBSD-style, stripped
> 
> 
> 
> From /usr/src/share/mk/bsd.linker.mk :
> 
> .if ${ld} == "LD" || (${ld} == "XLD" && ${XLD} != ${LD})
> .if !defined(${X_}LINKER_TYPE) || !defined(${X_}LINKER_VERSION)
> _ld_version!=   ${${ld}} --version 2>/dev/null | head -n 1 || echo none
> .if ${_ld_version} == "none"
> .error Unable to determine linker type from ${ld}=${${ld}}
> .endif
> 
> 
> Trying the failing line

Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work

2017-06-29 Thread Gerald Pfeifer 


Am 29. Juni 2017 18:55:59 GMT+08:00 schrieb Mark Millard :
>I'm not currently set up to run more than head on
>any of amd64, powerpc64, powerpc, aarch64, or armv6/7
>(which are all I target). And I'm in the middle of
>attempting a fairly large jump to head -r320458 on
>those.

Oh, then I had misunderstood your previous mail. No worries, I'll gently 
proceed then.

I expect to update gcc5 in the next 24 hours.

>[In my normal/head environment I'm switching to lang/gcc7-devel
>for gcc (from lang/gcc6 ) but I'm odd that way.]

The compiler should be fine, it's a number of ports that are not (even blocking 
the move from GCC 5 to 6 as default).

Gerald
___
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: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

2017-06-29 Thread Mark Millard 
[Good news from the llvm side of things. . .]

On 2017-Jun-29, at 3:47 AM, Dimitry Andric  wrote:

> On 29 Jun 2017, at 12:04, Mark Millard  wrote:
>> 
>> [The libc++ code in question appears to not be ready for
>> 32-bit contexts with 64 bit times. Disable
>> experimental/filesystem for now? I've submitted
>> llvm bugzilla 33638 for the issue and have
>> added it to llvm's 25780, the FreeBSD META for
>> clang.]
> 
> Yes, this also broke earlier on arm and mips, which is why there is the
> following in lib/Makefile:
> 
> .if ${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips"
> _libcplusplus+= libc++experimental
> .endif
> 
> I haven't yet found the time to address this issue.  Upstream should
> already be aware of it, though.
> 
> One nasty problem with this is that it is not possible to figure out at
> compile time what the size of time_t is.  You always need some sort of
> configure-time test, and an external define.

I got a notice of a pending patch for the issue:

Begin forwarded message:

From: bugzilla-daemon at llvm.org
Subject: [Bug 33638] FreeBSD head -r320347 moved TARGET_ARCH=powerpc to 64-bit 
time_t but now experimental/filesystem/operations.cpp fails static_asserts and 
such
Date: June 29, 2017 at 10:23:56 AM PDT
. . .
Comment # 2 on bug 33638 from Eric Fiselier
I have a patch for this waiting in the wings. I should be able to get to it
next week


===
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: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

2017-06-29 Thread Mark Millard 
On 2017-Jun-29, at 5:54 AM, Konstantin Belousov  wrote:
> 
> On Thu, Jun 29, 2017 at 12:47:10PM +0200, Dimitry Andric wrote:
>> One nasty problem with this is that it is not possible to figure out at
>> compile time what the size of time_t is.  You always need some sort of
>> configure-time test, and an external define.
> 
> It is arguably possible, with constexpr.

I took Dimitry's wording as probably referring to
testing the size in the C/C++ preprocessor like
the original code tests for __LP64__ being defined
vs. not to control what it does: extending that to
involve more preprocessor tests to pick from more
code blocks. (But it is a guess given his wording.)

I also took him to be excluding C++17's if-constexpr
(or that the limitations in where how it can be used
would prevent his intent) --and excluding the types of
meta-programming/Substitution-Failure-Is-Not-An-Error
usage that if-constexpr can simplify: too much rework
of parts of libc++.

Net result: extending the Makefile's "if" that he
referenced with a powerpc-family test removes
something in more contexts than have the problem.
I think that he was wishing for a simple way to
avoid that loss but still prevent the problem
cases.

===
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: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

2017-06-29 Thread Konstantin Belousov 
On Thu, Jun 29, 2017 at 12:47:10PM +0200, Dimitry Andric wrote:
> One nasty problem with this is that it is not possible to figure out at
> compile time what the size of time_t is.  You always need some sort of
> configure-time test, and an external define.

It is arguably possible, with constexpr.
___
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: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work

2017-06-29 Thread Mark Millard 

On 2017-Jun-29, at 3:10 AM, Gerald Pfeifer  wrote:

> Am 28. Juni 2017 22:38:52 GMT+08:00 schrieb Mark Millard  dsl-only.net>:
>> A primary test is building lang/gcc5-devel under release/11.0.1
>> and then using it under stable/11 or some draft of release/11.1.0 .
> 
> Thank you, Mark. Let me know how it went. In the meantime I'll prepare the 
> change for gcc5 itself.

I'm not currently set up to run more than head on
any of amd64, powerpc64, powerpc, aarch64, or armv6/7
(which are all I target). And I'm in the middle of
attempting a fairly large jump to head -r320458 on
those. (powerpc 32-bit and 64-bit just failed
for libc++ time-usage compiling now that 32-bit has
64-bit time_t, including in world32/lib32 contexts
for powerpc64.)

It will likely be a while before I manage to have a
11.x context (without losing my head contexts), much
less examples from all "my" 5 TARGET_ARCH's. (Given past
wchar_t type handling problems (e.g.) for gcc targeting
powerpc family members I think it should be checked.)
I'll have to find and set up disks: I do not even have
such handy/ready at the moment.

[I got into this area by being asked questions, not by
my direct use of release/11.0.1 , stable/11 , or a
draft of release/11.1.0 .]

I'll let you know when I have some test results but
others may get some before I do.

> . . .
>> Eventually most of the lang/gcc* 's will need whatever
>> technique is used.
> 
> Yes, agreed. Version 5 is most important since it's the default; then 6; 4.x 
> is for retro computing fans ;-), so 7 will then be next.

[In my normal/head environment I'm switching to lang/gcc7-devel
for gcc (from lang/gcc6 ) but I'm odd that way.]

===
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: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

2017-06-29 Thread Dimitry Andric 
On 29 Jun 2017, at 12:04, Mark Millard  wrote:
> 
> [The libc++ code in question appears to not be ready for
> 32-bit contexts with 64 bit times. Disable
> experimental/filesystem for now? I've submitted
> llvm bugzilla 33638 for the issue and have
> added it to llvm's 25780, the FreeBSD META for
> clang.]

Yes, this also broke earlier on arm and mips, which is why there is the
following in lib/Makefile:

.if ${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips"
_libcplusplus+= libc++experimental
.endif

I haven't yet found the time to address this issue.  Upstream should
already be aware of it, though.

One nasty problem with this is that it is not possible to figure out at
compile time what the size of time_t is.  You always need some sort of
configure-time test, and an external define.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work

2017-06-29 Thread Gerald Pfeifer 


Am 28. Juni 2017 22:38:52 GMT+08:00 schrieb Mark Millard :
>A primary test is building lang/gcc5-devel under release/11.0.1
>and then using it under stable/11 or some draft of release/11.1.0 .

Thank you, Mark. Let me know how it went. In the meantime I'll prepare the 
change for gcc5 itself.

>It looks like the the lang/gcc5-devel build still creates and
>uses the headers that go in include-fixed/ but that they are
>removed from $(STAGEDIR}${TARGLIB} 's tree before installation
>or packaging.
>
>So, if I understand right, lang/gcc5-devel itself still does use
>the adjusted headers to produce its own materials but when
>lang/gcc5-devel is used later it does not. Definitely
>something to be testing since it is a mix overall.

I am not worried about that since that should not cause any binary 
incompatibilities (ABI). The problem we encountered was about source code and 
API in a wide sense of that term.

>Is some form of exp-like run needed that tries to force use
>of a release/11.0.1 built lang/gcc5-devel (-r444563) to build
>other things under, say, stable/11  or some draft of
>release/11.1.0 ? Is this odd combination even possible
>currently?

I am not aware of it, and while originally I was thinking to request an -exp 
run (after the GCC version update which is dragging due to broken ports), time 
is not on our side and the change should be low risk.

> [altermative approach] But I guess that did not work out.

Not with my current level of connectivity and my notebook a dead brick on top 
of that. And my preference is to still build, but stow away (unless explicitly 
requested to keep).

>Eventually most of the lang/gcc* 's will need whatever
>technique is used.

Yes, agreed. Version 5 is most important since it's the default; then 6; 4.x is 
for retro computing fans ;-), so 7 will then be next.

Gerald
___
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: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

2017-06-29 Thread Mark Millard 
[The libc++ code in question appears to not be ready for
32-bit contexts with 64 bit times. Disable
experimental/filesystem for now? I've submitted
llvm bugzilla 33638 for the issue and have
added it to llvm's 25780, the FreeBSD META for
clang.]

On 2017-Jun-29, at 2:21 AM, Mark Millard  wrote:

> [TARGET_ARCH=powerpc64 fails similarly in its world32
> part of its build.]
> 
> On 2017-Jun-29, at 1:33 AM, Mark Millard  wrote:
> 
>> Beyond static_assert failures and overflow/underflow of long long
>> it also it complains in some cases about:
>> 
>> static_assert expression is not an integral constant expression
>> 
>> 
>> [I will note that attempting a gcc 4.2.1 build did not
>> stop and report such things for its libstdc++. The below
>> is somehow libc++ and/or clang 4 specific.]
>> 
>> 
>> Context:
>> 
>> # uname -apKU
>> FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT  r320458M  amd64 
>> amd64 1200036 1200036
>> 
>> buildworld for TARGET_ARCH=powerpc resulted in:
>> 
>> --- filesystem/operations.o ---
>> /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:579:1: 
>> error: static_assert failed ""
>> static_assert(is_representable({max_time_t, 9}), "");
>> ^ ~
>> /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:580:1: 
>> error: static_assert failed ""
>> static_assert(is_representable({max_time_t, 10}), "");
>> ^ ~~
>> /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:581:1: 
>> error: static_assert failed ""
>> static_assert(is_representable({min_time_t, 0}), "");
>> ^ ~
>> /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:603:1: 
>> error: static_assert failed ""
>> static_assert(!is_representable(file_time_type::max()), "");
>> ^ 
>> /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:604:1: 
>> error: static_assert failed ""
>> static_assert(!is_representable(file_time_type::min()), "");
>> ^ 
>> /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:15: 
>> error: static_assert expression is not an integral constant expression
>> static_assert(is_representable(file_time_type(seconds(max_time_t))), "");
>> ^
>> /usr/src/contrib/libc++/include/chrono:386:59: note: value 
>> 922337203685477580700 is outside the range of representable values of 
>> type 'long long'
>>  static_cast<_Ct>(__fd.count()) * 
>> static_cast<_Ct>(_Period::num)));
>> ^
>> /usr/src/contrib/libc++/include/chrono:413:12: note: in call to 
>> '&__duration_cast, 
>> std::__1::chrono::duration > 
>> >()->operator()(seconds(max_time_t))'
>>   return __duration_cast, _ToDuration>()(__fd);
>>  ^
>> /usr/src/contrib/libc++/include/chrono:560:26: note: in call to 
>> 'duration_cast(seconds(max_time_t))'
>>   : __rep_(_VSTD::chrono::duration_cast(__d).count()) 
>> {}
>>^
>> /usr/src/contrib/libc++/include/__config:390:15: note: expanded from macro 
>> '_VSTD'
>> #define _VSTD std::_LIBCPP_NAMESPACE
>> ^
>> /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:47: 
>> note: in call to 'duration(seconds(max_time_t), 0)'
>> static_assert(is_representable(file_time_type(seconds(max_time_t))), "");
>> ^
>> /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:15: 
>> error: static_assert expression is not an integral constant expression
>> static_assert(is_representable(file_time_type(seconds(min_time_t))), "");
>> ^
>> /usr/src/contrib/libc++/include/chrono:386:59: note: value 
>> -922337203685477580800 is outside the range of representable values of 
>> type 'long long'
>>  static_cast<_Ct>(__fd.count()) * 
>> static_cast<_Ct>(_Period::num)));
>> ^
>> /usr/src/contrib/libc++/include/chrono:413:12: note: in call to 
>> '&__duration_cast, 
>> std::__1::chrono::duration > 
>> >()->operator()(seconds(min_time_t))'
>>   return __duration_cast, _ToDuration>()(__fd);
>>  ^
>> /usr/src/contrib/libc++/include/chrono:560:26: note: in call to 
>> 'duration_cast(seconds(min_time_t))'
>>   : __rep_(_VSTD::chrono::duration_cast(__d).count()) 
>> {}
>>^
>> /usr/src/contrib/libc++/include/__config:390:15: note: expanded from macro 
>> '_VSTD'
>> #define _VSTD std::_LIBCPP_NAMESPACE
>> ^
>>

Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

2017-06-29 Thread Mark Millard 
[TARGET_ARCH=powerpc64 fails similarly in its world32
part of its build.]

On 2017-Jun-29, at 1:33 AM, Mark Millard  wrote:

> Beyond static_assert failures and overflow/underflow of long long
> it also it complains in some cases about:
> 
> static_assert expression is not an integral constant expression
> 
> 
> [I will note that attempting a gcc 4.2.1 build did not
> stop and report such things for its libstdc++. The below
> is somehow libc++ and/or clang 4 specific.]
> 
> 
> Context:
> 
> # uname -apKU
> FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT  r320458M  amd64 
> amd64 1200036 1200036
> 
> buildworld for TARGET_ARCH=powerpc resulted in:
> 
> --- filesystem/operations.o ---
> /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:579:1: 
> error: static_assert failed ""
> static_assert(is_representable({max_time_t, 9}), "");
> ^ ~
> /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:580:1: 
> error: static_assert failed ""
> static_assert(is_representable({max_time_t, 10}), "");
> ^ ~~
> /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:581:1: 
> error: static_assert failed ""
> static_assert(is_representable({min_time_t, 0}), "");
> ^ ~
> /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:603:1: 
> error: static_assert failed ""
> static_assert(!is_representable(file_time_type::max()), "");
> ^ 
> /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:604:1: 
> error: static_assert failed ""
> static_assert(!is_representable(file_time_type::min()), "");
> ^ 
> /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:15: 
> error: static_assert expression is not an integral constant expression
> static_assert(is_representable(file_time_type(seconds(max_time_t))), "");
>  ^
> /usr/src/contrib/libc++/include/chrono:386:59: note: value 
> 922337203685477580700 is outside the range of representable values of 
> type 'long long'
>   static_cast<_Ct>(__fd.count()) * 
> static_cast<_Ct>(_Period::num)));
>  ^
> /usr/src/contrib/libc++/include/chrono:413:12: note: in call to 
> '&__duration_cast, 
> std::__1::chrono::duration > 
> >()->operator()(seconds(max_time_t))'
>return __duration_cast, _ToDuration>()(__fd);
>   ^
> /usr/src/contrib/libc++/include/chrono:560:26: note: in call to 
> 'duration_cast(seconds(max_time_t))'
>: __rep_(_VSTD::chrono::duration_cast(__d).count()) 
> {}
> ^
> /usr/src/contrib/libc++/include/__config:390:15: note: expanded from macro 
> '_VSTD'
> #define _VSTD std::_LIBCPP_NAMESPACE
>  ^
> /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:47: 
> note: in call to 'duration(seconds(max_time_t), 0)'
> static_assert(is_representable(file_time_type(seconds(max_time_t))), "");
>  ^
> /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:15: 
> error: static_assert expression is not an integral constant expression
> static_assert(is_representable(file_time_type(seconds(min_time_t))), "");
>  ^
> /usr/src/contrib/libc++/include/chrono:386:59: note: value 
> -922337203685477580800 is outside the range of representable values of 
> type 'long long'
>   static_cast<_Ct>(__fd.count()) * 
> static_cast<_Ct>(_Period::num)));
>  ^
> /usr/src/contrib/libc++/include/chrono:413:12: note: in call to 
> '&__duration_cast, 
> std::__1::chrono::duration > 
> >()->operator()(seconds(min_time_t))'
>return __duration_cast, _ToDuration>()(__fd);
>   ^
> /usr/src/contrib/libc++/include/chrono:560:26: note: in call to 
> 'duration_cast(seconds(min_time_t))'
>: __rep_(_VSTD::chrono::duration_cast(__d).count()) 
> {}
> ^
> /usr/src/contrib/libc++/include/__config:390:15: note: expanded from macro 
> '_VSTD'
> #define _VSTD std::_LIBCPP_NAMESPACE
>  ^
> /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:47: 
> note: in call to 'duration(seconds(min_time_t), 0)'
> static_assert(is_representable(file_time_type(seconds(min_time_t))), "");
>  ^
> . . .
> --- lib__L ---
> 7 errors generated.
> *** [filesystem/operations.o] Error code 1
> 
> make[5]: stopped in /usr/src/lib/libc++experimental
>

head -r320458 (e.g.) amd64 -> powerpc cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

2017-06-29 Thread Mark Millard 
Beyond static_assert failures and overflow/underflow of long long
it also it complains in some cases about:

static_assert expression is not an integral constant expression


[I will note that attempting a gcc 4.2.1 build did not
stop and report such things for its libstdc++. The below
is somehow libc++ and/or clang 4 specific.]


Context:

# uname -apKU
FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT  r320458M  amd64 amd64 
1200036 1200036

buildworld for TARGET_ARCH=powerpc resulted in:

--- filesystem/operations.o ---
/usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:579:1: 
error: static_assert failed ""
static_assert(is_representable({max_time_t, 9}), "");
^ ~
/usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:580:1: 
error: static_assert failed ""
static_assert(is_representable({max_time_t, 10}), "");
^ ~~
/usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:581:1: 
error: static_assert failed ""
static_assert(is_representable({min_time_t, 0}), "");
^ ~
/usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:603:1: 
error: static_assert failed ""
static_assert(!is_representable(file_time_type::max()), "");
^ 
/usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:604:1: 
error: static_assert failed ""
static_assert(!is_representable(file_time_type::min()), "");
^ 
/usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:15: 
error: static_assert expression is not an integral constant expression
static_assert(is_representable(file_time_type(seconds(max_time_t))), "");
  ^
/usr/src/contrib/libc++/include/chrono:386:59: note: value 
922337203685477580700 is outside the range of representable values of type 
'long long'
   static_cast<_Ct>(__fd.count()) * 
static_cast<_Ct>(_Period::num)));
  ^
/usr/src/contrib/libc++/include/chrono:413:12: note: in call to 
'&__duration_cast, 
std::__1::chrono::duration > 
>()->operator()(seconds(max_time_t))'
return __duration_cast, _ToDuration>()(__fd);
   ^
/usr/src/contrib/libc++/include/chrono:560:26: note: in call to 
'duration_cast(seconds(max_time_t))'
: __rep_(_VSTD::chrono::duration_cast(__d).count()) {}
 ^
/usr/src/contrib/libc++/include/__config:390:15: note: expanded from macro 
'_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
  ^
/usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:47: 
note: in call to 'duration(seconds(max_time_t), 0)'
static_assert(is_representable(file_time_type(seconds(max_time_t))), "");
  ^
/usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:15: 
error: static_assert expression is not an integral constant expression
static_assert(is_representable(file_time_type(seconds(min_time_t))), "");
  ^
/usr/src/contrib/libc++/include/chrono:386:59: note: value 
-922337203685477580800 is outside the range of representable values of type 
'long long'
   static_cast<_Ct>(__fd.count()) * 
static_cast<_Ct>(_Period::num)));
  ^
/usr/src/contrib/libc++/include/chrono:413:12: note: in call to 
'&__duration_cast, 
std::__1::chrono::duration > 
>()->operator()(seconds(min_time_t))'
return __duration_cast, _ToDuration>()(__fd);
   ^
/usr/src/contrib/libc++/include/chrono:560:26: note: in call to 
'duration_cast(seconds(min_time_t))'
: __rep_(_VSTD::chrono::duration_cast(__d).count()) {}
 ^
/usr/src/contrib/libc++/include/__config:390:15: note: expanded from macro 
'_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
  ^
/usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:47: 
note: in call to 'duration(seconds(min_time_t), 0)'
static_assert(is_representable(file_time_type(seconds(min_time_t))), "");
  ^
. . .
--- lib__L ---
7 errors generated.
*** [filesystem/operations.o] Error code 1

make[5]: stopped in /usr/src/lib/libc++experimental
.ERROR_TARGET='filesystem/operations.o'
.ERROR_META_FILE='/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental/_usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib_libc++experimental_filesystem_operations.o.meta'
.MAKE.LEVEL='5'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='c++

Re: /usr/ports -r444615 (e.g.) & head -r320458 (e.g.): sysutils/u-boot-pine64 build fails for arch/arm/dts/pine64_plus.dtb source handling error (gic in a64.dtsi)

2017-06-29 Thread Emmanuel Vadot 

 Hello Mark,

On Wed, 28 Jun 2017 20:52:17 -0700
Mark Millard  wrote:

> On 2017-Jun-28, at 7:44 PM, Mark Millard  wrote:
> 
> > Is the below a BSDL vs. GPL DTS issue?
> > 
> > In my attempt to build sysutils/u-boot-pine64 I got:
> > 
> >  OBJCOPY u-boot.srec
> >  OBJCOPY u-boot-nodtb.bin
> > start=$(aarch64-none-elf-nm u-boot | grep __rel_dyn_start | cut -f 1 -d ' 
> > '); end=$(aarch64-none-elf-nm u-boot | grep __rel_dyn_end | cut -f 1 -d ' 
> > '); tools/relocate-rela u-boot-nodtb.bin 0x4a00 $start $end
> >  SYM u-boot.sym
> >  DTC arch/arm/dts/pine64_plus.dtb
> > Error at arch/arm/dts/.pine64_plus.dtb.dts.tmp:533:27: Expected unit address
> > gic: interrupt-controller@{
> >   ^
> > Error at arch/arm/dts/.pine64_plus.dtb.dts.tmp:533:27: Failed to find root 
> > node /.
> > gic: interrupt-controller@{
> >   ^
> > Failed to parse tree.
> > gmake[3]: *** [scripts/Makefile.lib:299: arch/arm/dts/pine64_plus.dtb] 
> > Error 1
> > gmake[2]: *** [dts/Makefile:36: arch-dtbs] Error 2
> > gmake[1]: *** [Makefile:821: dts/dt.dtb] Error 2
> > gmake[1]: *** Waiting for unfinished jobs
> > gmake[1]: Leaving directory 
> > '/usr/obj/portswork/usr/ports/sysutils/u-boot-pine64/work/u-boot-2016.05'
> > 
> > 
> > 
> > Looking at the gic part of the source. . .
> > 
> > # more 
> > /usr/obj/portswork/usr/ports/sysutils/u-boot-pine64/work/u-boot-2016.05/arch/arm/dts/a64.dtsi
> > . . .
> >gic: interrupt-controller@{
> >compatible = "arm,gic-400";
> >interrupt-controller;
> >#interrupt-cells = <3>;
> >#address-cells = <0>;
> > 
> >reg = <0x01C81000 0x1000>,
> >  <0x01C82000 0x2000>,
> >  <0x01C84000 0x2000>,
> >  <0x01C86000 0x2000>;
> >interrupts =  >  (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> >};
> > 

 Yes the node is wrong but if gpl dtc can handle that maybe we should
to, I'll try to find time to fix that.

> > 
> > I'll be trying 3 other u-boot-*'s so I may have more to
> > report later.
> 
> The other 3 that I tried worked fine:
> 
>   Installation of sysutils/u-boot-rpi2 (u-boot-rpi2-2015.04)
>   Installation of sysutils/u-boot-rpi3 (u-boot-rpi3-2017.01)
>   Installation of sysutils/u-boot-sinovoip-bpi-m3 
> (u-boot-sinovoip-bpi-m3-2016.05)
> 
> So this may be unique to a64.dtsi and its lack of
> hexadecimal digits after the "@" in what I quoted.
> 
> Still, sysutils/u-boot-pine64 used to build. So it may
> be a BSDL vs. GPL DTS issue as far as the handling of
> the notation goes.
> 
> ===
> Mark Millard
> markmi at dsl-only.net

 I also a patch waiting for comment on the u-boot mailing list
that add the possibility to specify which dtc to use, this will be
needed for the next u-boot for arm64 board as it uses 'incbin'
directive which bsd dtc doesn't support yet (David is looking into it).

 Anyway, new u-boot should be out around july 10th so I'll update the
port right after.

 Thanks for reporting.

-- 
Emmanuel Vadot  
___
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"