On Thu, 6 Apr 2017, Bernd Edlinger wrote:
> On 04/06/17 09:55, Richard Biener wrote:
> > On Thu, 6 Apr 2017, Jakub Jelinek wrote:
> >
> >> On Thu, Apr 06, 2017 at 09:47:10AM +0200, Richard Biener wrote:
> >>> @@ -955,6 +960,7 @@ get_alias_set (tree t)
> >>> Just be pragmatic here and make sure the array and its element
> >>> type get the same alias set assigned. */
> >>> else if (TREE_CODE (t) == ARRAY_TYPE
> >>> + && ! TYPE_TYPELESS_STORAGE (t)
> >>> && (!TYPE_NONALIASED_COMPONENT (t)
> >>> || TYPE_STRUCTURAL_EQUALITY_P (t)))
> >>> set = get_alias_set (TREE_TYPE (t));
> >>> @@ -1094,6 +1100,15 @@ get_alias_set (tree t)
> >>>
> >>> TYPE_ALIAS_SET (t) = set;
> >>>
> >>> + if (TREE_CODE (t) == ARRAY_TYPE
> >>> + && TYPE_TYPELESS_STORAGE (t))
> >>
> >> Shouldn't TYPE_TYPELESS_STORAGE apply even for non-array types?
> >> If somebody chooses to store anything in long long
> >> __attribute__((typeless_storage)), so be it. Or what kind of complications
> >> do you see for that?
> >
> > It's a new feature so I don't see why we should allow that. Given that
> > people will have to do sth when the compiler doesn't support it the
> > only "reliable" way of using it is on an array of char anyway.
> >
> > The complication starts when people use it on a type that currently
> > uses alias-set zero (because "zero" doesn't get an alias_set_entry).
> >
>
> The typeless_storage does not need to implement all the C++ semantic
> by itself. It would be possible, but then it is not as generic as
> it could be. What I'd really like to have is make an arbitrary
> type behave as if it were a char with respect to aliasing.
>
> In my mind, the typeless_storage attribute has a value of its own,
> but it can be used to implement the C++17 semantic of std::byte [N].
>
> So I would not want to completely change the way TBAA is working
> today. I believe it is doing a fairly good job.
>
> The TBAA machinery, does for instance not need to propagate this
> attribute from the member to the enclosing struct that is
> also not done for a struct that contains a char.
>
> I think it is not too complicated to done in the C++ FE.
> The FE looks for array of std::byte and unsigned char,
> and sets the attribute when the final type is constructed.
>
> What I am trying to do is just extend the semantic of may_alias
> a bit, and then have the C++ FE use it in the way it has to.
>
> Here is what I want to write in the doc:
>
> @item typeless_storage
> @cindex @code{typeless_storage} type attribute
> A type declared with this attribute behaves like a character type
> with respect to aliasing semantics.
> This is attribute is similar to the @code{may_alias} attribute,
> except that it is not restricted to pointers.
>
> Example of use:
>
> @smallexample
> typedef int __attribute__((__typeless_storage__)) int_a;
>
> int
> main (void)
> @{
> int_a a = 0x12345678;
> short *b = (short *) &a;
>
> b[1] = 0;
>
> if (a == 0x12345678)
> abort();
>
> exit(0);
> @}
> @end smallexample
>
>
> we should first agree on that.
I don't see anyone needing the above example, it's not going to be
portable in any way.
Please don't invent sth that invites users to write bad code.
I'd even restrict it to work on arrays of chars only!
(arrays of byte-size integer types)
Richard.
