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 19:16, Mark Millard wrote: > > 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

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

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, a

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.

Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'

2017-06-29 Thread Hans Petter Selasky
On 06/29/17 13:16, Hans Petter Selasky wrote: On 06/26/17 15:03, O. Hartmann wrote: On Mon, 26 Jun 2017 14:48:58 +0200 Gary Jennejohn wrote: On Mon, 26 Jun 2017 14:00:48 +0200 "O. Hartmann" wrote: On Mon, 26 Jun 2017 13:26:08 +0200 Gary Jennejohn wrote: On Mon, 26 Jun 2017 10:29:47 +0200

Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'

2017-06-29 Thread Hans Petter Selasky
On 06/26/17 15:03, O. Hartmann wrote: On Mon, 26 Jun 2017 14:48:58 +0200 Gary Jennejohn wrote: On Mon, 26 Jun 2017 14:00:48 +0200 "O. Hartmann" wrote: On Mon, 26 Jun 2017 13:26:08 +0200 Gary Jennejohn wrote: On Mon, 26 Jun 2017 10:29:47 +0200 "O. Hartmann" wrote: Over the past

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 >

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

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 expr

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 l