> Sorry to interrupt here, but please finish the existing partial C++ > transitions > instead of starting to work on new ones. Current stage1 will not last forever > (stage1 is usually 6 months, so its natural end would be end of September). > I'd rather have the current transition to a symbol table finished than having > that half-way done and half-way done in C++. Please.
I am focusing on getting the transition finished for 4.8. Some discussion about C++ transition (I would like to see done for 4.8 at least in the basic and obvious way) and problems people have with the current design seems good to me. We do not need to implement everything discussed in this thread immediately, but it is good to have the discussion. > > Btw, I also think the current symtab hierarchy is somewhat flawed. At > the core a symtab entry should just be the symbol name and a list > of entities associated with it (much similar to the LTO symtab stuff). We do have that. There is list of symtab entries sharing the same symtab hash entry (assembler name). I have WIP patch to make lto-symtab to use these instead of its own hashes. They need more testing and bit of cleanup though. > Entities then are callgraph nodes, varpool nodes or alias nodes (or other Having alias nodes separate from callgrap/varpool is difficult thing. The problem is that one realy wants to handle function aliases as functions and variable aliases as variables (i.e. one want to have call to function alias, or read from variable alias but not other ways around). Thus we currently have aliases inherited from functions/variables both on tree declaration level and symbol table level. I have patches to commonize more the alias handling that is now duplicated over former cgraph/vaprool in queue though. > stuff). Thus, the current symtab_node_base is too "fat", and decls, > instead of having DECL_ASSEMBLER_NAME should have a pointer > to the (new) symtab node they are associated with. Yes, it is the longer term goal (or rather getting rid of assembler name in favor of real symbol name + flags that are currently encoded in assembler name) At the moment it does seem to make sense though when everything is tied to declarations and eclarations have their own assembler name. I will slowly work on this, but after 4.8. Honza > > Thanks, > Richard.
