> 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 de nitions.
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
