[PATCH] D31022: Implement P0298R3: `std::byte`

[Richard Smith via cfe-commits]

On 5 July 2017 at 14:29, James Y Knight <jyknight at google.com> wrote:

> I actually didn't know that attribute existed. It does look like the right
> thing to use here. However, unfortunately, it appears it doesn't work for
> enum class in clang [[1]]. It *does* seem to work in GCC.
>
> Unfortunately, it seems that GCC has actually hardcoded the type name
> "std::byte" (in gcc/cp/decl.c). To be compatible with libstdc++, we'll
> either need to fix libstdc++ to use also may_alias, or also hardcode the
> name. The former seems like it ought to be an acceptable patch.
>

Hardcoding the name would be consistent with what we do for other library
types that the core language explicitly blesses (such as
std::initializer_list, std::type_info, std::bad_alloc, std::align_val_t). I
expect we will want the compiler to be able to identify "this is std::byte"
internally anyway, for diagnostic purposes (and one day probably for
constant expression evaluation, due to the "provides storage" rules).


> [[1]] E.g. Given:
> namespace std { enum class __attribute__((may_alias)) byte  : unsigned
> char {}; }
> int foo(std::byte* x) { return (int)*x; }
>
> Running:
> bin/clang -O2 -S -std=c++1z -emit-llvm -o - test.cc
>
> still has:
>   %0 = load i8, i8* %x, align 1, !tbaa !2
> ...
> !2 = !{!3, !3, i64 0}
> !3 = !{!"_ZTSSt4byte", !4, i64 0}
>
>
>
> On Wed, Jul 5, 2017 at 3:51 PM, David Majnemer via cfe-commits <
> cfe-commits at lists.llvm.org> wrote:
>
>> FWIW, doesn't this just need a may_alias attribute on the definition?
>> On Wed, Jul 5, 2017 at 2:39 PM James Y Knight via Phabricator via
>> cfe-commits <cfe-commits at lists.llvm.org> wrote:
>>
>>> jyknight added a comment.
>>>
>>> Ping. I don't think this got resolved, and I really wouldn't like to
>>> see  released in this state...can you either revert this from the library,
>>> or implement the compiler support, before the 5.0 release branch?
>>>
>>> In https://reviews.llvm.org/D31022#716702, @jyknight wrote:
>>>
>>> > I believe this needs compiler support, too, in order to treat
>>> >
>>> >   namespace std { enum class byte : unsigned char {}; }
>>> >
>>> > as directly having tbaa type "omnipotent char" instead of a subtype.
>>> >
>>> > That is, given:
>>> >
>>> >   void foo(char* x, int *y) {
>>> >     x[1] = char(y[0] & 0xff);
>>> >     x[0] = char((y[0] & 0xff00) >> 8);
>>> >   }
>>> >
>>> > the compiler assumes that x and y might alias each-other, and thus
>>> must have two loads of y[0]. If you replace "char" with "std::byte", the
>>> same should happen, but as of now does not.
>>>
>>>
>>>
>>>
>>>
>>> https://reviews.llvm.org/D31022
>>>
>>>
>>>
>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170705/df528350/attachment.html>