[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Fixing build with clang 7 and 64-bit Linux
From: |
Greg Chicares |
Subject: |
Re: [lmi] Fixing build with clang 7 and 64-bit Linux |
Date: |
Mon, 12 Nov 2018 18:06:14 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 |
On 2018-11-11 19:52, Vadim Zeitlin wrote:
[...]
> https://github.com/vadz/lmi/pull/103
https://github.com/vadz/lmi/pull/103/commits/07fba915f6d250dfab5ee06bc79fe88ac75efeef
| facets.cpp:118:50: error: constant expression evaluates to -8193 which
| cannot be narrowed to type 'std::ctype_base::mask' (aka 'unsigned
| short') [-Wc++11-narrowing]
|
| when using clang by simply removing the braces, which impose C++11
| initialization and forbidding narrowing, and allowing the implicit cast
| to unsigned short to take place.
...
| // See "Implementation note" above.
| - constexpr std::ctype_base::mask z = {~std::ctype_base::space};
| + constexpr std::ctype_base::mask z = ~std::ctype_base::space;
See the cited "Implementation note". I think that one or more of
{gcc; clang; the C++11 and C++17 standards}
is incorrect. Let's figure out exactly what's wrong, and reconsider
the other workarounds discussed in that note, before working around
the present workaround.
Does clang compile Dietmar Kuehl's original
rc[C] &= ~std::ctype_base::space;
without warning? and if not, then should it?
C++11 and C++17 both [bitmask.types] prescribe:
| constexpr bitmask operator~(bitmask X){
| return static_cast<bitmask>(~static_cast<int_type>(X));
| }
| bitmask& operator&=(bitmask& X, bitmask Y){
| X = X & Y; return X;
| }
...
| To clear a value Y in an object X is to evaluate the expression X &=~ Y.
and I don't see any error there. (This paper:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3110.html
cited in the "Implementation note" seems to have been accepted;
its main point is that some enums elsewhere needed to be changed,
but that doesn't affect <ctype>.)
Thus,
~Y
is of type bitmask and the prescribed "clear a value" operation
X &= ~Y
is valid; doesn't that mean that Kuehl's original
rc[C] &= ~std::ctype_base::space;
is strictly conforming? If so, then maybe only gcc is wrong, and
only gcc needs any workaround (which can later be removed when
they correct the problem), but for clang we can just revert to
the original because it has always been correct.
But is clang also wrong, perhaps in a different way than gcc?
It complains about line 118:
constexpr std::ctype_base::mask z = {~std::ctype_base::space};
"constant expression evaluates to -8193"
but the standard says:
| constexpr bitmask operator~(bitmask X){
| return static_cast<bitmask>(~static_cast<int_type>(X));
| }
so is clang saying that 'static_cast<bitmask>' fails to cast its
value to type <bitmask>? Or did they omit that static_cast in
their standard library implementation?
- [lmi] Fixing build with clang 7 and 64-bit Linux, Vadim Zeitlin, 2018/11/02
- Re: [lmi] Fixing build with clang 7 and 64-bit Linux, Greg Chicares, 2018/11/11
- Re: [lmi] Fixing build with clang 7 and 64-bit Linux, Vadim Zeitlin, 2018/11/11
- Re: [lmi] Fixing build with clang 7 and 64-bit Linux,
Greg Chicares <=
- Re: [lmi] Fixing build with clang 7 and 64-bit Linux, Vadim Zeitlin, 2018/11/12
- Re: [lmi] Fixing build with clang 7 and 64-bit Linux, Greg Chicares, 2018/11/13
- Re: [lmi] Fixing build with clang 7 and 64-bit Linux, Vadim Zeitlin, 2018/11/13
- Re: [lmi] Fixing build with clang 7 and 64-bit Linux, Greg Chicares, 2018/11/13
- Re: [lmi] Fixing build with clang 7 and 64-bit Linux, Vadim Zeitlin, 2018/11/13
- Re: [lmi] Fixing build with clang 7 and 64-bit Linux, Vadim Zeitlin, 2018/11/13