Test failure: darwin-sections.c

[fxcoudert]

darwin-sections.c

The only difference with the expected assembly is the generation of this:

/* A zero-sized object.  */
typedef struct _empty {} e_s;
/* These should go into __DATA,__bss */
static e_s sea;

which gives:

        .globl _al_256
        .zerofill __DATA,__common,_al_256,8,8
        .zerofill __DATA,__bss,_sea,1,3

where the testcase expects a different alignment:

        .zerofill __DATA,__bss,_sea,1,0

I'm a bit puzzled as to whether this is expected or not, actually. The _Alignof operator applied to sea returns 1, which would match what the testcase expects… but maybe being in a common makes it different?

[iains]

The next step on this is to do side-by-side with clang to make sure that we are producing the correct ABI.

Empty objects on Darwin (notwithstanding C++17+ rules) should occupy 1 byte of storage (for reasons to do with the ld64 atom model) and there's no reason for that to have excess alignment (that I can see) if there's no __attribute__((__align__())).

So, unless the rules have changed for aarch64, I'd say the test case expects the Right Thing and we're generating wrong code.

but.. let's check what clang does (section, alignment and size) - noting that you should add -fno-common to the clang flags (since that's what GCC defaults to now).

[fxcoudert]

That test explicitly passes -fcommon. clang agrees with the expectation from the testcase:

.zerofill __DATA,__bss,_sea,1,0         ; @sea

[iains]

ah my bad, it's testing that indeed.

OK that's one for the TODO :)

[fxcoudert]

Actually I think for that one, -fcommon and -fno-common do the same thing.

[iains]

hmm .. I cannot quite see where the variable is picking up the excess alignment.

• linux does this too, it seems (noting that Darwin's output is log2 of align and GAS is using align directly)

         .local  sea
        .comm   sea,0,8

(note that the size is OK to be zero on Linux, it has to be bumped to 1 on darwin because of the ld64 model).

• looking at the point that the backend gets the var to output it - the decl references the type e_s which is correctly shown as 0-sized, and having an alignment of 1. However the decl for sea has already gained the excess alignment at this point (it's not output path in the backend that is adding it).

... unfortunately tree dumps are not much use for tracing variables.

prob next is to ask the aarch64 folks whether this is an ABI mandate (I do not recall reading it in the AAPCS64).

[iains]

patch for testing.

[iains]

fixed - TODO is maybe to decide if there is ever a case that the extra alignment really brings some performance gain - but IMO that would only be something to do for >= O1 (and not for Os or Oz)