[AArch64][ARM] Why fpack-struct=4 has a higher priority than attribute

[LukeSTM]

struct s1
{
  int __attribute__ ((aligned (8))) a;
};

struct
{
  char c;
  struct s1 m;
} v;

int
main (void)
{
  if ((int)&v.m & 7)
    abort ();
  exit (0);
}

compile with only one option：-fpack-struct=4

gcc could pass this testcase, but clang could not.
https://godbolt.org/z/h5T5rdYWb

The code can be simplified as follows:

struct s1
{
  int __attribute__ ((aligned (8))) a;
}s;

https://godbolt.org/z/EbGsEz6eP

if compile without -fpack-struct=4, the alignment of struct is 8, as same as attribue. But if compile with -fpack-struct=4, the alignment of struct is 4. Why fpack-struct=4 has a higher priority than attribute? I think attribute should has a higher priority than Compilation options

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: Luke (LukeSTM)

``` struct s1 { int __attribute__ ((aligned (8))) a; };

struct
{
char c;
struct s1 m;
} v;

int
main (void)
{
if ((int)&v.m & 7)
abort ();
exit (0);
}

compile with only one option：-fpack-struct=4

gcc could pass this testcase, but clang could not.
https://godbolt.org/z/h5T5rdYWb

The code can be simplified as follows:

struct s1
{
int attribute ((aligned (8))) a;
}s;

https://godbolt.org/z/EbGsEz6eP
![image](https://github.com/user-attachments/assets/a052017d-5d28-4ceb-862c-e400c022492c)

if compile without -fpack-struct=4, the alignment  of struct is 8, as same as attribue. But if compile with -fpack-struct=4, the alignment  of struct is 4. Why fpack-struct=4 has a higher priority than attribute? I think attribute should has a higher priority than Compilation options




</details>

[LukeSTM]

attribute ((packed)) has a higher priority than fpack-struct=4

https://godbolt.org/z/j3x8P93z3

[LukeSTM]

It seem like llvm prefer a small alignment.
If attribute ((align (4))) and fpack-struct=8, alignment = 4.
If attribute ((align (4))) and fpack-struct, alignment = 1.
https://godbolt.org/z/ddeMvzEGE

[hstk30-hw]

Is this an expected behavior? CC @AaronBallman @zygoloid

[LukeSTM]

[LukeSTM]

I understand that the alignment rules of the structures of gcc and llvm should be the same, but the default alignment rules are different.
gcc arm struct alignment default 4byte，and could not less than 4byte。llvm does not have this restriction.

[AaronBallman]

This isn't ARM-specific, you get the same behavior with x86-64, for example.

This has been Clang's behavior for at least 15 years, see 0720944. I wonder how much ABI breakage there would be from changing behavior now. That said, I think the attribute should override the command line flag because the usual user expectation is that attributes take precedence over pragmas which take precedence over command line flags. The closer you are to the source, the higher priority the marking should be.

CC @dwblaikie @erichkeane @rjmccall for ideas and opinions

[erichkeane]

This isn't ARM-specific, you get the same behavior with x86-64, for example.

This has been Clang's behavior for at least 15 years, see 0720944. I wonder how much ABI breakage there would be from changing behavior now. That said, I think the attribute should override the command line flag because the usual user expectation is that attributes take precedence over pragmas which take precedence over command line flags. The closer you are to the source, the higher priority the marking should be.

CC @dwblaikie @erichkeane @rjmccall for ideas and opinions

I concur as far as that. The ABI break would be unfortunate/pretty annoying. At minimum we'd need to do the ClangABI tag change for this, but I'd probably want us to have some sort of warning diagnostic of "this has changed, use ClangABI=19 if you care".

[rjmccall]

It's actually less of a serious ABI issue that you'd probably think because -fpack-struct is unusable in most scenarios — any command line flag that changes struct layout is inherently wildly ABI-breaking.

[AaronBallman]

It's actually less of a serious ABI issue that you'd probably think because -fpack-struct is unusable in most scenarios — any command line flag that changes struct layout is inherently wildly ABI-breaking.

Oh that's a good point... that flag would change packing for every structure, including ones pulled in via system headers.

[rjmccall]

It's actually less of a serious ABI issue that you'd probably think because -fpack-struct is unusable in most scenarios — any command line flag that changes struct layout is inherently wildly ABI-breaking.

Oh that's a good point... that flag would change packing for every structure, including ones pulled in via system headers.

Right. There's a pragma that's less global, but I'm pretty sure that turns into the attribute rather than this global setting.