Open hikari-no-yume opened 3 years ago
Ah, interesting, yes that seems like another particular and peculiar exception to the way these have been handled. Since there isn't something similar in C89, we might need to handle a GEP of these values (at any point in the struct) as being special: they are a GEP of the previous value + sizeof the previous value + re-alignment. Using the address of the next value might add in padding instead that shouldn't have been present in the address computation. (similarly, omitting these might currently be losing padding due to zero-byte alignments, but that seems unlikely someone would be observing and depending on that)
When targeting pure C89, one way to achieve the same thing is to use a single-element array instead. We could do that, but this would only work if this struct isn't included in any other structs, and only for the final member of the struct…
In C99 you can put an array at the end of a struct with no size specified, a so-called “flexible array member”. In C89, I think some compilers support specifying an explicit size of 0 as an extension.
Here's a C program demonstrating it:
When compiled with
clang -O1
(haven't tested anything else), this results in LLVM IR with a zero-sized array in the struct, which is GEP'd. Because we don't emit struct members with zero-sized types, the CBE C output for this doesn't compile.I probably won't fix this bug any time soon since it's rather C-specific, and I'm mostly interested in compiling non-C languages to C. But I suppose a similar pattern could appear in another language's LLVM IR. I'm reporting this just for completeness really.