Open Radar

 
Summary:
The Objective-C @encode() directive silently produces incorrect descriptions for vector types. For example, 

Steps to Reproduce:
Compile and run the following:

typedef struct { int a; __m128 v; int b; } Test1;
typedef struct { int a; int b; } Test2;

int main(void)
{
    printf("%s   %zi\n", @encode(Test1), sizeof(Test1));
    printf("%s   %zi\n", @encode(Test2), sizeof(Test2));
}


Expected Results:
The two types, which have different sizes and layouts, should have different encodings.

Ideally, an encoding using the already-defined _C_VECTOR token ("!") would be used. For example, this might take the form "!16[4f]", where 16 is the alignment requirement in bytes and [4f] is the existing encoding for an array of four floats.

Alternatively, a complete failure to encode the type would be preferable to the status quo. Simply skipping fields can lead to undesirable hilarity if, for instance, an object pointer type follows a vector type.

Actual Results:
Both types encode as "{?=ii}".

Regression:
None known.

Notes:
This also happens with Clang ext_vector_type types, e.g. typedef float fv4 __attribute__((ext_vector_type(4)));.

In an ideal world, it would be sufficient to encode vector types as an array or struct using existing notation, but it isn’t because of the extra alignment constraints on vectors.