This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix more of C/fortran canonical type issues
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Richard Biener <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org, burnus at net-b dot de
- Date: Mon, 8 Jun 2015 18:54:52 +0200
- Subject: Re: Fix more of C/fortran canonical type issues
- Authentication-results: sourceware.org; auth=none
- References: <20150608001957 dot GA35779 at kam dot mff dot cuni dot cz> <20150608050047 dot GA10381 at kam dot mff dot cuni dot cz> <20150608054500 dot GA58209 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1506081536560 dot 30088 at zhemvz dot fhfr dot qr> <20150608150627 dot GB23542 at kam dot mff dot cuni dot cz> <alpine dot DEB dot 2 dot 10 dot 1506081648580 dot 25225 at digraph dot polyomino dot org dot uk>
> On Mon, 8 Jun 2015, Jan Hubicka wrote:
>
> > Joseph, I may be wrong, but I believe that the cross-compilation-unit
> > representation compatibility (in C standard sense) is however not an
> > equivalence class, so it can't be fully represented by TYPE_CANOINICAL
>
> Indeed, type compatibility is not transitive, but the expressed intention
> of WG14 in response to DR#314 is that in a valid program it should be
> possible to merge the translation units, unifying structure and union
> types across translation units (with renaming as needed).
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)
or
a.c
int *a;
b.c:
unsigned int *a;
or
a.c
struct a {int a;} a;
b.c:
struct a {unsigned int a} a;
so I assume the following is no longer valid
a.c:
struct a {int a;} *a;
b.c:
struct a *a;
struct a *b;
c.c:
struct b {float a;} *a;
as we may figure out that struct a in b.c does not have unique completetion.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com