On Thu, May 18, 2017 at 11:08:51AM -0400, Nathan Sidwell wrote: > On 05/16/2017 11:26 AM, Nathan Sidwell wrote: > > This patch breaks apart the creation of the pass manager from > > gcc::context's ctor. This will allow us to register additional dumps > ... https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01295.html > > This patch builds upon the context creation patch (this diff includes it), > to implement a new LANG_HOOK_REGISTER_DUMPS language hook. I call it > between creating the dump manager and instantiating the optimization passes. > > The patch then uses the hook to move the current -fdump-class-hierarchy > option into the C++ FE entirely, removing TDI_class and associated handling > from dumpfile and c-family/c-opts.c. The option gets renamed to > -fdump-lang-class in the process. > > Obviously -fdump-translation-unit is the next candidate, and possibly > -fdump-tree-original.
This breaks the dump numbering. On some simple source file with some OpenMP pragmas in it, with C and -fopenmp -fdump-tree-all I'm getting (so unless one knows the order of passes, the indexes and file order no longer reveal the actual pass sequence): 1.c.003t.omplower 1.c.003t.original 1.c.004t.gimple 1.c.004t.lower 1.c.007t.eh 1.c.008t.cfg 1.c.009t.ompexp ... The right order is .original, .gimple, then (not included) .nested, then .omplower, .lower, etc. With C++ -fopenmp -fdump-tree-all I'm getting: 1.c.003t.original 1.c.004t.gimple 1.c.005t.omplower 1.c.006t.lower 1.c.008t.ehopt 1.c.009t.eh ... which is slightly better, but there is no space for e.g. the .nested dump. With -fopenmp -fdump-tree-all -fdump-lang-all and C++ I'm getting 1.c.003t.original 1.c.004l.raw 1.c.004t.gimple 1.c.005t.omplower 1.c.006t.lower 1.c.008t.ehopt 1.c.009t.eh ... so there is a number clash in between the raw and gimple dumps in addition to the nested vs. omplower. So, first question, where should we order the -fdump-lang-* dumps, shall they go before .original/.gimple/.nested, or in between .original and .gimple/.nested, or after those 3 (the last option looks just wrong to me)? Shall the 3 standard dumps be registered like any others? Shall the number of lang dumps affect the numbering, i.e. is it desirable that with C and C++ you get different numbers for *t.cfg dump, or *t.gimple? In many cases it would be better if the numbering was consistent between C and C++. Jakub