From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105782 invoked by alias); 16 Jun 2015 13:30:18 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 105772 invoked by uid 89); 16 Jun 2015 13:30:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Jun 2015 13:30:17 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7CFE33C; Tue, 16 Jun 2015 06:30:31 -0700 (PDT) Received: from e105689-lin.cambridge.arm.com (e105689-lin.cambridge.arm.com [10.2.207.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C983A3F447; Tue, 16 Jun 2015 06:30:14 -0700 (PDT) Message-ID: <558024E5.7080709@foss.arm.com> Date: Tue, 16 Jun 2015 13:30:00 -0000 From: Richard Earnshaw User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eric Botcazou , gcc-patches@gcc.gnu.org Subject: Re: [patch 6/6] scalar-storage-order merge: testsuite References: <3247494.5bgQPARZRk@polaris> <2831431.ZZiNchhqJ9@polaris> In-Reply-To: <2831431.ZZiNchhqJ9@polaris> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg01125.txt.bz2 On 16/06/15 10:52, Eric Botcazou wrote: > This is the testsuite part. > > testsuite/ > * c-c++-common/sso-1.c: New test. > * c-c++-common/sso: New directory. > * gcc.dg/sso-1.c: New test. > * g++.dg/sso-1.C: Likewise. > * gcc.dg/sso: New directory. > * g++.dg/sso: Likewise. > * gnat.dg/sso1.adb: New test. > * gnat.dg/sso2.ad[sb]: Likewise. > * gnat.dg/sso3.adb: Likewise. > * gnat.dg/sso4.adb: Likewise. > * gnat.dg/sso5.adb: Likewise. > * gnat.dg/sso6.adb: Likewise. > * gnat.dg/sso7.adb: Likewise. > * gnat.dg/specs/sso1.ads: Likewise. > * gnat.dg/specs/sso2.ads: Likewise. > * gnat.dg/sso: New directory. > It appears that all the C tests check the specific syntactic form 'struct __attr_sso__ foo {...};' What is the impact of changing the location of __attr_sso__? Eg: struct foo {...} __attr_sso__; (Note that alignment attributes can have significant impact depending on where in the syntax the attribute is placed (I'm expecting this will be true here as well). What about with typedefs? Can I apply the attribute to a previously laid out struct? Can I apply it to individual fields in the struct, eg: struct bar { int a; int __attr_sso__ b; }; Can I modify an existing struct to create an opposite endian variant? Eg. struct bar { int a; }; struct wibble { struct __attr_sso__ bar a; }; Assuming mixed fields in a struct are possible, can it be applied to individual bitfields? What is the impact on mixing big and little endian bitfields in the same structure. R.