From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 70ECA3858D28 for ; Tue, 23 Nov 2021 14:16:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 70ECA3858D28 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F1E5E1042; Tue, 23 Nov 2021 06:16:51 -0800 (PST) Received: from [10.57.26.21] (unknown [10.57.26.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 633023F66F; Tue, 23 Nov 2021 06:16:51 -0800 (PST) Subject: Re: [PATCH 2/2][GCC] arm: Declare MVE types internally via pragma To: Murray Steele Cc: gcc-patches@gcc.gnu.org References: <55ba6a8c-4dda-c023-0e93-a052e4830d06@arm.com> <342ef4e3-6013-2d67-adc8-6310febe2f52@foss.arm.com> <2a59e081-0a5f-5b9b-c398-d89c6c217822@arm.com> From: Richard Earnshaw Message-ID: Date: Tue, 23 Nov 2021 14:16:49 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <2a59e081-0a5f-5b9b-c398-d89c6c217822@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3493.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 14:16:54 -0000 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.