Consider such cases:
Case 1:
struct f
{
double x[0]; /* This is a GNU extension. */
double a;
double b;
};Case 2:
struct f
{
float x[0];
float b;
};Case 3:
struct f
{
double x[0];
float b;
};Current calling convention doc is not clear on "if f::x is considered a member", "if f::x is considered a floating-point member", and "if f::x is considered one float (or double) member". Note that we are saying:
Empty structures are ignored by C compilers which support them as a non-standard extension
But it does not cover "empty" arrays.
And current GCC trunk is doing strange things (IMO). For Case 2, it passes b in FAR. But for Case 3, it passes b in GAR.
In my opinion the most "clear" solution is to ignore the empty arrays (and bitfields: https://gcc.gnu.org/PR102024) altogether with empty aggreates. But that will requires to update GCC behavior, fortunately we still have an oppertunity to do this before GCC 12 release (if we move fast). CC GCC maintainers: @ChenghuaXu @chenglulu
Another solution is to document the current GCC behavior clearly in the doc. But I don't know to write it (as I consider the current behavior "strange").
Consider such cases:
Case 1:
Case 2:
Case 3:
Current calling convention doc is not clear on "if
f::xis considered a member", "iff::xis considered a floating-point member", and "iff::xis considered onefloat(ordouble) member". Note that we are saying:But it does not cover "empty" arrays.
And current GCC trunk is doing strange things (IMO). For Case 2, it passes
bin FAR. But for Case 3, it passesbin GAR.In my opinion the most "clear" solution is to ignore the empty arrays (and bitfields: https://gcc.gnu.org/PR102024) altogether with empty aggreates. But that will requires to update GCC behavior, fortunately we still have an oppertunity to do this before GCC 12 release (if we move fast). CC GCC maintainers: @ChenghuaXu @chenglulu
Another solution is to document the current GCC behavior clearly in the doc.
But I don't know to write it(as I consider the current behavior "strange").