On Fri, 13 Jun 2025 16:41 Segher Boessenkool wrote: > On Fri, Jun 13, 2025 at 08:21:34PM +0100, Tom V wrote: > > On Fri, 13 Jun 2025 13:37 Segher Boessenkool wrote: > > > On Fri, Jun 13, 2025 at 06:52:19PM +0100, Tom V wrote: > > > > Suppose I declare: > > > > typedef int a_type; > > typedef int __attribute__((aligned(1))) b_type; > > > > a_type * a; > > b_type * b; > > > > a is a pointer to a normally aligned int. > > b is a pointer to a possibly unaligned int. > > > Any time the compiler generates a read or write access to *b it > > correctly generates only instructions that work at non-aligned > > addresses. > > I'm not sure how to parse what you say here. The compiler will > generate whatever code it wants to generate to access an "int", and > that code might not work correctly (or at all) with the datum > underaligned (for the ABI, for the ISA, for whatever :-) ) No. You are completely wrong. The compiler correctly generates one kind of code when it is accessing an "aligned int" and another kind of code when it is accessing an "unaligned int". It is always guaranteed to work in either case, as long as the value of the pointer is the address of an instance of what it is declared as pointing to. The only time it could not work is if you assign a the address of an "unaligned int" to the pointer declared as pointing to "aligned int" and then dereference it. If you still don't understand, think of the typedef as being similar to declaring a packed struct with a single member. Hopefully you understand that the compiler generates different code when accessing a member of a packed struct. Since the compiler can already do exactly what I need, I am just asking if there is any rationale behind why I have to follow a convoluted two-step procedure involving typedef (or one-member packed struct) rather than just declaring my pointer with the required attribute.
