On 18/11/2021 15:45, Richard Earnshaw wrote:
>
> This is mostly OK, but can't we reduce the number of tests somewhat? For
> example, I think you can merge type_redef_13.c and type_redef_14.c by writing
>
> /* { dg-do compile } */
> /* { dg-require-effective-target arm_v8_1m_mve_ok } */
> /* { dg-add-options arm_v8_1m_mve } */
>
> int uint8x16x4_t; /* { dg-message "note: previous declaration of
> 'uint8x16x4_t'" } */
> int uint16x8x2_t; /* { dg-message "note: previous declaration of
> 'uint16x8x2_t'" } */
>
> #pragma GCC arm "arm_mve_types.h" /* { dg-error {'uint8x16x4_t' redeclared}
> } */
> /* { dg-error {'uint16x8x2_t' redeclared} {target *-*-*} .-1 } */
>
> etc. Note the second dg-error is anchored to the line above it (.-1).
>
> R.
Thanks. I think if we'd like to reduce the number of tests, it would make the
most
sense to merge the test cases in the way you've described based on their
implementation
and target features. i.e.
- type_redef_1.c : covers mve_pred16_t.
- type_redef_2.c : covers single-integer-vector types.
- type_redef_3.c : covers single-float-vector types.
- type_redef_4.c : covers integer-vector-tuple types.
- type_redef_5.c : covers float-vector-tuple types.
The idea being that the test results for these tests should allow someone to
triangulate
the cause of the failure. For example, if tests 4 and 5 fail, it is likely due
to a
deficiency in the MVE tuple type implementation, rather than the handling of
target-specific
features. More specific tests failures can be determined by looking through log
files.
Thanks,
Murray
