#133 Disparity between CIL and GCC in struct/union merging

[Anonymous]

In the attached two files (file1.c and file2.c, combined into one file), "struct myStruct" is defined two different ways, each holding a slightly different anonymous union:
//file1.c
union {
long long int i;
int* p;
char c;
};
//file2.c
union {
long long int i;
double f;
};

Using gcc and ar, I can compile these two files together into a single object file without errors.
gcc -c file1.c
gcc -c file2.c
ar cruv out.a file1.o file2.o
However, using cilly and attempting to merge these two with the following commands:
cilly --merge -c file1.c
cilly --merge -c file2.c
cilly --merge --mode=AR cruv out.a file1.o file2.o
I get the following error from CIL:

👎 Error: Incompatible declaration for build (from file2.o(1)).
Previous was at file1.c:13 (from file1.o (0))
Failed assumption that struct myStruct and struct myStruct are isomorphic (different number of fields in __anonunion____missing_field_name_24 and __anonunion____missing_field_name_24: 3 != 2.)
struct myStruct {
int a ;
union __anonunion____missing_field_name_24 __annonCompField1 ;
};

struct myStruct {
int a ;
union __anonunion____missing_field_name_24 __annonCompField1 ;
};

Final merging phase (0): file1.o
Final merging phase (1): file2.o
file2.c:12: Warning: The name build is used for two distinct globals
Error: There were errors during merging

This is a trivial example of the error I'm getting in a larger project that I am trying to merge together. I am using CIL 1.5.1, downloaded earlier today from SourceForge.

[Anonymous]

Contains file1.c and file2.c

[Gabriel Kerneis]

I believe we have a case of defined behaviour here, and CIL is correct to complain (but gcc/ar cannot spot the issue because of staged compilation). I have asked for confirmation to people more knowledgeable than myself on the issue.

[Gabriel Kerneis]

It is not explicitly an undefined behaviour (the standard only talks about incompatible types for objects, not struct definition per se), but it still seems valid to reject such a construct. I might reconsider it in case you were able to provide a real-world example with a rationale for the observed behaviour.