>
> 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
