public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>
To: "Paul Koning" <paulkoning@comcast.net>,
	"Markus Fröschle" <markus@mubf.de>
Cc: gcc@gcc.gnu.org
Subject: Re: asking for __attribute__((aligned()) clarification
Date: Mon, 19 Aug 2019 14:01:00 -0000	[thread overview]
Message-ID: <055f71a6-7b20-eb80-6f0a-d7572c34fa47@arm.com> (raw)
In-Reply-To: <1E465204-0887-49CB-8472-196EDE7AAE81@comcast.net>

On 19/08/2019 14:57, Paul Koning wrote:
> 
> 
>> On Aug 19, 2019, at 8:46 AM, Markus Fröschle <markus@mubf.de> 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 <stdint.h>
>>
>> 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.

  reply	other threads:[~2019-08-19 14:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-19 12:46 "Markus Fröschle"
2019-08-19 13:57 ` Paul Koning
2019-08-19 14:01   ` Richard Earnshaw (lists) [this message]
2019-08-19 14:08     ` Alexander Monakov
2019-08-19 14:12       ` Paul Koning
2019-08-20  5:46       ` Aw: " "Markus Fröschle"
2019-08-21 14:29         ` Alexander Monakov
2019-08-21 14:32           ` Paul Koning
2019-08-21 14:58             ` Alexander Monakov
2019-08-21 16:50               ` Paul Koning
2019-08-21 17:35                 ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=055f71a6-7b20-eb80-6f0a-d7572c34fa47@arm.com \
    --to=richard.earnshaw@arm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=markus@mubf.de \
    --cc=paulkoning@comcast.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).