Closed daym closed 2 years ago
m68k (gcc 8.2.0):
Type Alignment/Bytes Size/Bytes
int8_t 1 1
int16_t 2 2
int32_t 2 4
int64_t 2 8
__int128 not supported
uint8_t 1 1
uint16_t 2 2
uint32_t 2 4
uint64_t 2 8
float 2 4
double 2 8
long double 2 12
size_t 2 4
off_t 2 4
void* 2 4
Does it make sense to have the alignments and sizes for other compilers than gcc/llvm?
I don't know, you tell me. Though if the libraries these compilers create interoperate with libraries other compilers create then those alignments and sizes have to be equal between compilers anyway.
Alignment sizes are dictated by the ABI which is usually independent of the compiler used.
See for example: https://wiki.osdev.org/System_V_ABI
@glaubitz sure, but offsets are, AFAICT, implementation specific in the sense that there's no restriction to put a uint16_t in the first 2 bytes or the last ones in a struct where the uint16_t is before a uint32_t.
But wouldn't that make any code compiled with a different compiler ABI-incompatible with standard Linux environments, for example?
It would. But I mostly thinking of bare metal code and embedded systems where the problem is not that obvious and using the same compiler is the go to solution.
Okay, but bare-metal code doesn't use the SysV ABI anyway, so we're talking about different things then.
There are now assertions in the generated C code to ensure that the size+alignment match what mrustc expected.
This issue collects the alignment of struct members on gcc.
The following program has been run:
On armhf, this results in: b_offset = 2, b_size = 2.
Then I modified it accordingly to get:
armhf (both gcc 7.3.0 and gcc 5.4.0):
x86_64 (gcc 7.3.0):
i686 (gcc 7.3.0):