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

[James Y Knight via cfe-commits]

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.


[[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/0133f072/attachment.html>