| Message ID | 53627D0B.6050309@arm.com |
|---|---|
| State | New |
| Headers | show |
Ping~ Originally posted here: http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00019.html Thanks, Yufeng On 05/01/14 17:57, Yufeng Zhang wrote: > Hi, > > This patch documents issues with singleton vector types in the 4.9 > AArch64 backend. > > "On AArch64, the singleton vector types int64x1_t, uint64x1_t and > float64x1_t exported by arm_neon.h are defined to be the same as their > base types. This results in incorrect application of parameter passing > rules to arguments of types int64x1_t and uint64x1_t, with respect to > the AAPCS64 ABI specification. In addition, names of C++ functions with > parameters of these types (including float64x1_t) are not mangled > correctly. The current typedef declarations also unintentionally > allow implicit casting between singleton vector types and their base > types. These issues will be resolved in a near future release. See > PR60825 for more information." > > OK for the wwwdocs repos? > > Thanks, > Yufeng
Ping^2 Thanks, Yufeng On 05/08/14 17:38, Yufeng Zhang wrote: > Ping~ > > Originally posted here: > > http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00019.html > > Thanks, > Yufeng > > On 05/01/14 17:57, Yufeng Zhang wrote: >> Hi, >> >> This patch documents issues with singleton vector types in the 4.9 >> AArch64 backend. >> >> "On AArch64, the singleton vector types int64x1_t, uint64x1_t and >> float64x1_t exported by arm_neon.h are defined to be the same as their >> base types. This results in incorrect application of parameter passing >> rules to arguments of types int64x1_t and uint64x1_t, with respect to >> the AAPCS64 ABI specification. In addition, names of C++ functions with >> parameters of these types (including float64x1_t) are not mangled >> correctly. The current typedef declarations also unintentionally >> allow implicit casting between singleton vector types and their base >> types. These issues will be resolved in a near future release. See >> PR60825 for more information." >> >> OK for the wwwdocs repos? >> >> Thanks, >> Yufeng > > >
On 1 May 2014 17:57, Yufeng Zhang <Yufeng.Zhang@arm.com> wrote: > "On AArch64, the singleton vector types int64x1_t, uint64x1_t and > float64x1_t exported by arm_neon.h are defined to be the same as their > base types. This results in incorrect application of parameter passing > rules to arguments of types int64x1_t and uint64x1_t, with respect to > the AAPCS64 ABI specification. In addition, names of C++ functions with > parameters of these types (including float64x1_t) are not mangled > correctly. The current typedef declarations also unintentionally > allow implicit casting between singleton vector types and their base > types. These issues will be resolved in a near future release. See > PR60825 for more information." Looks fine to me. Go ahead. /Marcus
Index: htdocs/gcc-4.9/changes.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v retrieving revision 1.69 diff -u -r1.69 changes.html --- htdocs/gcc-4.9/changes.html 29 Apr 2014 18:31:24 -0000 1.69 +++ htdocs/gcc-4.9/changes.html 1 May 2014 15:01:02 -0000 @@ -33,6 +33,20 @@ announcement</a>.</li> </ul> </li> + + <li><p>On AArch64, the singleton vector types <code>int64x1_t</code>, + <code>uint64x1_t</code> and <code>float64x1_t</code> exported by + <code>arm_neon.h</code> are defined to be the same as their base types. + This results in incorrect application of parameter passing rules to + arguments of types <code>int64x1_t</code> and <code>uint64x1_t</code>, + with respect to the AAPCS64 ABI specification. In addition, names of + C++ functions with parameters of these types (including + <code>float64x1_t</code>) are not mangled correctly. The current + <code>typedef</code> declarations also unintentionally allow implicit + casting between singleton vector types and their base types. These + issues will be resolved in a near future release. See + <a href="http://gcc.gnu.org/PR60825">PR60825</a> for more information. + </p></li> </ul> <p>