From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15259 invoked by alias); 19 Aug 2019 14:01:20 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 14950 invoked by uid 89); 19 Aug 2019 14:01:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:1E46520, HTo:D*comcast.net, H*i:sk:1E46520, HX-Languages-Length:1742 X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Aug 2019 14:00:59 +0000 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 EF4F228; Mon, 19 Aug 2019 07:00:42 -0700 (PDT) Received: from e120077-lin.cambridge.arm.com (e120077-lin.cambridge.arm.com [10.2.206.91]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 630873F718; Mon, 19 Aug 2019 07:00:42 -0700 (PDT) Subject: Re: asking for __attribute__((aligned()) clarification To: Paul Koning , =?UTF-8?Q?Markus_Fr=c3=b6schle?= Cc: gcc@gcc.gnu.org References: <1E465204-0887-49CB-8472-196EDE7AAE81@comcast.net> From: "Richard Earnshaw (lists)" Message-ID: <055f71a6-7b20-eb80-6f0a-d7572c34fa47@arm.com> Date: Mon, 19 Aug 2019 14:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <1E465204-0887-49CB-8472-196EDE7AAE81@comcast.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-08/txt/msg00137.txt.bz2 On 19/08/2019 14:57, Paul Koning wrote: > > >> On Aug 19, 2019, at 8:46 AM, Markus Fröschle wrote: >> >> All, >> >> this is my first post on these lists, so please bear with me. >> >> My question is about gcc's __attribute__((aligned()). Please consider the following code: >> >> #include >> >> typedef uint32_t uuint32_t __attribute__((aligned(1))); >> >> uint32_t getuuint32(uint8_t p[]) { >> return *(uuint32_t*)p; >> } >> >> This is meant to prevent gcc to produce hard faults/address errors on architectures that do not support unaligned access to shorts/ints (e.g some ARMs, some m68k). On these architectures, gcc is supposed to replace the 32 bit access with a series of 8 or 16 bit accesses. >> >> I originally came from gcc 4.6.4 (yes, pretty old) where this did not work and gcc does not respect the aligned(1) attribute for its code generation (i.e. it generates a 'normal' pointer dereference, consequently crashing when the code executes). To be fair, it is my understanding that the gcc manuals never promised this *would* work. > > That has never been my understanding. I've always read the manual to say that "aligned" only INCREASES the alignment. The normal alignment is that specified by the ABI for the given data type (often, but not always, the size of the primitive type) -- or it is 1 for "packed". > > So I use __attribute__ ((packed)) to request byte alignment, and, say, __attribute__ ((packed, aligned(2))) to specify alignment to 2 byte multiples. > > paul > > Correct, but note that you can only pack structs and unions, not basic types. there is no way of under-aligning a basic type except by wrapping it in a struct. R.