On 23/11/2021 09:37, Murray Steele wrote:
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
Merged files will still have the same number of tests, and the same possible test names, just from fewer source files. So I don't think triangulation will be an issue.
