Date: Thu, 29 Jun 2017 10:16:30 -0700 From: Mark Millard <markmi@dsl-only.net> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Dimitry Andric <dim@FreeBSD.org>, Justin Hibbits <jhibbits@FreeBSD.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: 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) Message-ID: <22F5CFA1-E6A9-4C41-BD43-967105B44C49@dsl-only.net> In-Reply-To: <20170629125407.GM1935@kib.kiev.ua> References: <D8AB364D-9E4B-470A-A858-842E73530C3B@dsl-only.net> <5B12D9A6-C9A2-4B0D-B32D-D04D7DB1E3BC@dsl-only.net> <AFCE7DA0-E8D2-4FC7-9E2F-78011E54F1A0@dsl-only.net> <55A1694D-BC40-49AE-BEF7-CEE502126E96@FreeBSD.org> <20170629125407.GM1935@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Jun-29, at 5:54 AM, Konstantin Belousov <kostikbel at gmail.com> = wrote: >=20 > 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. >=20 > 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. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22F5CFA1-E6A9-4C41-BD43-967105B44C49>