Re: Improve LTO type checking during symtab merging

[Jan Hubicka <hubicka@ucw.cz>]

> 
> Only emitting the warnings with -Wodr looks good to me.  I can't see
> how we can decide what cases lead to wrong code surprises and what not

OK, I will go with -Wodr for all the warnings then, that seems fine to me.

> (other than using types_compatible_p ...).  Wrong-code can only(?) happen
> if we happen to inline in a way that makes the incosistency visible in
> a single function.
>  
> > Incrementally I am heading towards proper definition of decl 
> > compatibility that I can plug into symtab merging and avoid merging 
> > incompatible decls (so FORTIFY_SOURCE works).
> >
> > lto-symtab and ipa-icf both have some knowledge of the problem, I want to get
> > both right and factor out common logic.
> 
> Sounds good.
>  
> > Other improvement is to preserve the ODR type info when non-ODR variant
> > previals so one can diagnose clash in between C++ units even in mixed
> > language linktimes.
> 
> Hmm, but then merging ODR with non-ODR variant is already pointing to
> a ODR violation?  So why do you need to retain that info?

non-ODR type is compatible with all ODR types that are structurally equivalent,
but these ODR types may not be compatible with each other.  For example:

a.c
struct a {int a;} var;

b.C
extern struct a {int a;} var;

c.C
extern struct b {int a;} var;

has ODR violatio nbetween b.C and c.C, but because the variable is defined
in C source file, we will only check compatibility with non-ODR struct a.
My plan is to simply record if the declaration also has ODR type associated
with it.  But that is for incremental improvement.
> 
> Btw, there is that old PR41227 which has both wrong-code and diagnostic
> impact...

Thanks, I will take deeper look. I did not know that fortran has way
to mark types that are supposed to interpoerate outside fortran units.
This may be potentially interesting.


Honza