Re: Plan needed for switching m68k to 32-bit alignment

On Sun, 27 Oct 2024, Thorsten Glaser wrote:

> >https://gcc.gnu.org/wiki/RustFrontEnd
> 
> That’s assuming it can build the same stuff the same way so it can be 
> used in packaging.
> 

Not an assumption. I simply pointed out an opportunity for collaboration, 
because I see the primary problem facing the m68k port is a lack of 
resources.

> >I expect alignment assumptions like that will end up putting more 
> >platforms in the same predicament in future.
> 
> No, all the other platforms use natural alignment.
> 
> >"Natural" alignment is meaningless in the context of portable data
> >structures, as they exist without reference to any particular integer
> 
> Yeah, but in practice, all we have is ILP32 and LP64; 

... for now.

> the Windows® world has LLP64 in addition. And natural alignment just 
> means that all the data types’ alignment is their size. (Which kind of 
> makes sense, so you can read them without getting an unalignment trap on 
> SPARC or so.)
> 

That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the 
case on my Linux/i686 system. 4 != 8:

struct baa {
        int a;
        long long b;
} foo;

> >Q. What is the size of this struct, assuming baa.b is naturally aligned?
> >
> >struct baa {
> >        int a;
> >        long long b;
> >};
> 
> For ILP32, LP64 and LLP64, it’s 4 (a) + 4 (padding) + 8 (b) = 16 chars.

So natural alignment is portable if you first assume a data model. But the 
struct definition itself is not portable, since it doesn't specify a data 
model.

> More importantly, and relevant for Qt, struct baa is also 8-byte
> aligned...
> 

If the struct itself is not naturally aligned, it too will eventually 
break someone's assumption of natural alignment.