4 ms·

I thought you were right, but I tested it on x86_64 GNU/Linux with this struct: struct ts { int32_t dword1; int64_t qword1;

by 256_ 2y ago

I thought you were right, but I tested it on x86_64 GNU/Linux with this struct: struct ts { int32_t dword1; int64_t qword1; int32_t dword2; }; Writing -1 to all 3 members and printing out the individual bytes up to sizeof(struct ts), it produces this with -O0 and -O3: FF FF FF FF 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF 00 00 00 00 With -Os, I get some garbage data after the last member (always those 2 byte positions, with different values every time): FF FF FF FF 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF 45 76 00 00 I feel like I'm missing something obvious here. Or maybe my system's ABI is a weird exception.

jabl 2y ago
Was this with x86_64? The point of the parent was about x86_32, I believe.
- 256_ 2y ago
  Oh yes, I really was missing something obvious. And you did, too, since I mentioned the architecture in the first line of my post.
  - jabl 2y ago
    I did see it, but was unsure if you meant you were compiling for a 32-bit target on a 64-bit host.
AshamedCaptain 2y ago
In addition to the confusion about x86 and x86_64/amd64, you should also know that -O[s123] cannot possibly influence the padding of structures, or it would mean you could not link a library compiled with -Os with a program compiled with -O3 (or viceversa).
- account42 2y ago
  In theory the compiler could change the padding of structures if it can prove that this never leaks out of the translation unit. Of course, printing the size or bits of the structure would inhibit that.