------=_Part_5172_1745717449.1459187302194
Content-Type: multipart/alternative;
 boundary="----=_Part_5173_1736659520.1459187302194"

------=_Part_5173_1736659520.1459187302194
Content-Type: text/plain; charset=UTF-8

Have there been any proposals to standardize the GCC and Clang extension
[[gnu::may_alias]]?

I think that may_alias is a good compromise between the needs of low-level
programmers like me and the needs of compiler optimizers.  We'd be able to
do our reinterpret_casts without worrying about aliasing rules so much.

may_alias already finds use in vector extensions like __m128, so that
vectors operations can access the primitive types without painful memcpys
everywhere.

Melissa

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/540be00e-6f4f-44cf-ad12-434908dda017%40isocpp.org.

------=_Part_5173_1736659520.1459187302194
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Have there been any proposals to standardize the GCC and C=
lang extension [[gnu::may_alias]]?<br><br>I think that may_alias is a good =
compromise between the needs of low-level programmers like me and the needs=
 of compiler optimizers.=C2=A0 We&#39;d be able to do our reinterpret_casts=
 without worrying about aliasing rules so much.<br><br>may_alias already fi=
nds use in vector extensions like __m128, so that vectors operations can ac=
cess the primitive types without painful memcpys everywhere.<br><br>Melissa=
<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/540be00e-6f4f-44cf-ad12-434908dda017%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/540be00e-6f4f-44cf-ad12-434908dda017=
%40isocpp.org</a>.<br />

------=_Part_5173_1736659520.1459187302194--
------=_Part_5172_1745717449.1459187302194--

.

> may_alias already finds use in vector extensions like __m128, so that
> vectors operations can access the primitive types without painful
> memcpys everywhere.

Usually, most compilers optimize those memcpy anyway. We've been using
those for ages without ill-effects.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/56F9703C.8080603%40gmail.com.

.

On 2016/03/29 2:48 +0900, Myriachan wrote:
> Have there been any proposals to standardize the GCC and Clang extension
> [[gnu::may_alias]]?

I remember N4150:
Alias-Set Attributes: Toward restrict-like aliasing semantics for C++
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4150.pdf

Though I don't know which is less or more.

--
k_satoda

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/56FC0250.1000204%40f2.dion.ne.jp.

.

--001a11c3e7c8bcada8052f47e2bc
Content-Type: text/plain; charset=UTF-8

On 30 March 2016 at 17:44, Kazutoshi Satoda <k_satoda@f2.dion.ne.jp> wrote:

> On 2016/03/29 2:48 +0900, Myriachan wrote:
> > Have there been any proposals to standardize the GCC and Clang extension
> > [[gnu::may_alias]]?
>
> I remember N4150:
> Alias-Set Attributes: Toward restrict-like aliasing semantics for C++
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4150.pdf
>
> Though I don't know which is less or more.


N4150 appears to be significantly more powerful, since it also allows to
say that two pointers to the same type may not alias in a way that is nicer
than restrict, which is not very useful in generic programming.
gnu::may_alias, however, standardizes existing practice.

The problem with both of these is that they're viral, need to apply to both
pointers and references, and the attribute can usually be casted out, which
breaks the code.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya9407Zm2axqA%2BfKkwUcXLOFooNE9X_P%2BbWVjaBzZoQSKA%40mail.gmail.com.

--001a11c3e7c8bcada8052f47e2bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 3=
0 March 2016 at 17:44, Kazutoshi Satoda <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:k_satoda@f2.dion.ne.jp" target=3D"_blank">k_satoda@f2.dion.ne.jp</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 2016=
/03/29 2:48 +0900, Myriachan wrote:<br>
&gt; Have there been any proposals to standardize the GCC and Clang extensi=
on<br>
&gt; [[gnu::may_alias]]?<br>
<br>
</span>I remember N4150:<br>
Alias-Set Attributes: Toward restrict-like aliasing semantics for C++<br>
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4150.pd=
f" rel=3D"noreferrer" target=3D"_blank">http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/2014/n4150.pdf</a><br>
<br>
Though I don&#39;t know which is less or more.</blockquote><div><br></div><=
div>N4150 appears to be significantly more powerful, since it also allows t=
o say that two pointers to the same type may not alias in a way that is nic=
er than restrict, which is not very useful in generic programming.<br>gnu::=
may_alias, however, standardizes existing practice.</div><div><br></div><di=
v>The problem with both of these is that they&#39;re viral, need to apply t=
o both pointers and references, and the attribute can usually be casted out=
, which breaks the code.</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALnjya9407Zm2axqA%2BfKkwUcXLOFooNE9X=
_P%2BbWVjaBzZoQSKA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya9407Zm=
2axqA%2BfKkwUcXLOFooNE9X_P%2BbWVjaBzZoQSKA%40mail.gmail.com</a>.<br />

--001a11c3e7c8bcada8052f47e2bc--

.