On Tue, 19 Jan 2016, Jan Hubicka wrote: > > On Tue, 19 Jan 2016, Jan Hubicka wrote: > > > > > Hi, > > > here is updated patch. It has same effect as the former version. > > > > > > Bootstrapped/regtested x86_64-linux, OK? > > > > But what about the comment? > > > > We track no > > information on whether given type is used or not, so we have > > to keep them even when not emitting debug information, > > otherwise we may end up remapping variables and their (local) > > types in different orders depending on whether debug > > information is being generated. */ > > > > which suggests that the TYPE_DECLs somehow "order" remapping > > of local types and that is somehow important (maybe for VLA > > types which refer to locals). OTOH local vars are also > > duplicated in order before copying stmts (which may introduce > > differences because of seeing debug stmts or not refering to > > decls/types). > > The original patch is here: > https://gcc.gnu.org/ml/gcc-patches/2011-01/msg01344.html > my understand is that it is all about DECL_UID being stable with -g0 > and -g. My patch does not change that becuase I drop ignored and redundant > typedefs even with -g.
Yes, I see that but the comment suggests there are 2nd-order effects because those TYPE_DECLs you remove serve as "ordering" point for refered types and decls during inlining (as we remap blocks and their decls and refered-to vars first). The thing that would make the order -g dependent would be remapping a type or decl when remapping a debug stmt. Not sure if anything else is required to refer to them "first" (local vars for example). Richard.
