"David Mathog" <[email protected]> writes:
> Ian Lance Taylor <[email protected]> wrote:
>
>> Your changes are relying on a gcc extension which was only recently
>> added, more recently than those tests were added to the testsuite. Only
>> recently did gcc acquire the ability to use [] to access elements in a
>> vector.
>
> That isn't what my changes did. The array accesses are to the arrays in
> the union - nothing cutting edge there. The data is accessed through
> the array specified by .d (or .s etc.) not to name.x[index].
Oh, sorry, completely misunderstood. In that case, it seems to me that
your changes are causing the tests to no longer test what they should:
the code generation resulting from the specific gcc builtins, now
available as a gcc extension.
> Would changing the use of inlined functions to defines let the compiler
> digest it better? For instance:
>
> static __inline __m128i __attribute__((__always_inline__))
> _mm_andnot_si128 (__m128i __A, __m128i __B)
> {
> return (~__A) & __B;
> }
>
> becomes
>
> #define _mm_andnot_si128(A,B) (~A & B)
>
> That approach will get really messy for the more complicated _mm*.
I can't think of any reason why that would help.
> In general terms, can somebody give me a hint as to the sorts of things
> that if found in inlined functions might cause the compiler to optimize
> to invalid code?
The usual issue is invalid aliasing; see the docs for the
-fstrict-aliasing option. I don't know if that is the problem here.
Ian
