On Mon, 17 Jun 2013, Jan Hubicka wrote: > > On 06/17/2013 09:35 AM, Jan Hubicka wrote: > > >To get meaningful warnings, we need to know what decls/types are subject > > >to ODR. Do you think you can make C++ FE to drop a flag so middle-end know? > > >We can LTO ODR and non-ODR languages together. > > > > Basically everything in C++ is subject to the ODR. There are two > > cases: either there can be only one definition anywhere (e.g. normal > > variables and functions, anything local to such a function) or all > > definitions need to be identical. > > Does ODR hold also for extern "C" declarations in C++? > > > > > In C, you can treat all structurally identical types as the same, right? > > Sort of. Currently we have two notions of equivalency of types > > 1) TYPE_CANONICAL that is strictly merged by structural equivalence. > The equivalency is defined by gimple_canonical_types_compatible_p > and is very conservative (i.e. ignores type names for example) > > This is what drives most of backend and aliasing machinery. > > Having false equivalences leads to worse TBAA, false nonequivalences > leads to wrong code due to aliasing.
That's 100% accurate. > 2) Richard's type (and now tree) merging. This merging is conservative > on what is considered to be equivalent type and compare pretty > much everything in the in-memory type representaion (i.e. names, modifiers, > BINFOs, stuff that matters for debug or devirt machinery) > > false equivalences leads to loss of debug info quality and false > devirtualizations, false nonequivalences leads to explossions of memory > use and streaming time for Firefox or any other huge LTO build. There should not be false equivalencies - false equivalencies can lead to random bugs including wrong-code. Basically we consider two tree SCCs equivalent if all values inside them are equal and the tree SCC is structurally equivalent. > At least this is my understanding, Richard know more ;) > > ODR adds third notion of equivalency that should sit strictly in between > and in fact perhaps for ODR types we can make 1)=2)=ODR unless ODR is > obviously violated. The question is when will two types be "ODR equivalent" but not "tree equivalent". Certainly there is no such thing as "ODR" for C, so given C++ manually implemented in C you cannot expect same "vtable" contents when the types have the same name. Richard.
