https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68484
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |x86_64-*-*, i?86-*-*
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2015-11-23
CC| |hjl.tools at gmail dot com
Component|c++ |target
Ever confirmed|0 |1
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
As the summary mentions 'volatile' I'll also point to the implementation of the
intrinsics which have
/* Store four SPFP values. The address must be 16-byte aligned. */
extern __inline void __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_store_ps (float *__P, __m128 __A)
{
*(__v4sf *)__P = (__v4sf)__A;
}
so they are not using a volatile qualified type to access *__P which means
the stores are not considered volatile by GCC.
The arguments about strict-aliasing requirements still hold, only __m128 is
declared as __may_alias__:
/* The Intel API is flexible enough that we must allow aliasing with other
vector types, and their scalar components. */
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
/* Internal data types for implementing the intrinsics. */
typedef float __v4sf __attribute__ ((__vector_size__ (16)));
so the v4sf store has regular TBAA rules applied (and the __may_alias__ on
the by value passed __A has no effect).
-> target "bug", but I'd say an INVALID one.
HJ, I remember the "master" copy of the intrinsics documentation is somewhere
at Intel - what does that say to the two above issues?
Thus all of this boils down to the question whether the intrinsics are
implemented correctly (as documented). The volatile part of it would
mean to either pessimize all users or that we can't implement the
intrinsics as C functions.
