> On Mon, 8 Jun 2015, Jan Hubicka wrote: > > > Thank you. It is interesting that the DR exists. We do have comments about > > possibly completing the types by equiality established by the symbol table > > but I tought it is strictly invalid. Not sure how much that buy us though. > > As for specific examples. Shall we warn for > > > > a.c: > > int a; > > > > b.c: > > unsigned int a; > > > > (this seems perfectly valid by C/Fortran rules) > > That's clearly invalid (declarations of the same object with incompatible > types). int and unsigned int can alias, but declarations still need to be > consistent.
OK, so following the wording of the standard we have 2 All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. in 6.2.7. The int and unsigned int is not considered compatible. However the memory accesses are further discussed in 6.5 7 An object shall have its stored value accessed only by an lvalue expression that has one of the following types: 1 a type compatible with the effective type of the object, 2 a qualified version of a type compatible with the effective type of the object, 3 a type that is the signed or unsigned type corresponding to the effective type of the object, 4 a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object, 5 an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or 6 a character type So this is where the basic c_get_alias rules come from. i.e. 1-4 basically boils down to ignoring qualifiers and signedness and 6 is about dropping char into alias set 0, so this gives us some extra rules for TBAA compatibility that however does not propagate up when building canonical types during LTO. So we don't really need to ignore signedness for C/C++ only programs while building canonical types (that correspond to the symmetric and transitive closure of the notion of compatible types). In C/Fortran mixed units however C_SIZE_T (that is signed type) is interoperable with size_t (that is unsigned type) and this propagates up by: A Fortran derived type is interoperable with a C struct type if and only if the Fortran type has the BIND attribute (4.5.2), the Fortran derived type and the C struct type have the same number of components, and the components of the Fortran derived type would interoperate with corresponding components of the C struct type as described in 15.3.5 and 15.3.6 if the components were variables. A component of a Fortran derived type and a component of a C struct type correspond if they are declared in the same relative position in their respective type denitions. So clearly Fortran's structure containing C_SIZE_T sould interoperate with struct {size_t val;}. So we do need to ignore TYPE_UNSIGNED when processing fields of structures in C/fortran mixed programs and we should not warn on a variable being declared both as size_t and C_SIZE_T. Honza