On Wed, Aug 15, 2012 at 05:21:04PM +0200, Martin Jambor wrote: > Hi, > > On Fri, Aug 10, 2012 at 04:57:41PM +0200, Eric Botcazou wrote: > > > - ada/gcc-interface/utils.c:rest_of_subprog_body_compilation calls > > > dump_function which in turns calls dump_function_to_file which calls > > > push_cfun. But Ada front end has its idea of the > > > current_function_decl and there is no cfun which is an inconsistency > > > which makes push_cfun assert fail. I "solved" it by temporarily > > > setting current_function_decl to NULL_TREE. It's just dumping and I > > > thought that dump_function should be considered middle-end and thus > > > middle-end invariants should apply. > > > > If you think that calling dump_function from > > rest_of_subprog_body_compilation > > is a layering violation, I don't have a problem with replacing it with a > > more > > "manual" scheme like the one in c-family/c-gimplify.c:c_genericize, > > provided > > that this yields roughly the same output. > > Richi suggested on IRC that I remove the push/pop_cfun calls from > dump_function_to_file. The only problem seems to be > dump_histograms_for_stmt
Yesterday I actually tried and it is not the only problem. Another one is dump_function_to_file->dump_bb->maybe_hot_bb_p which uses cfun to read profile_status. There may be others, this one just blew up first when I set cfun to NULL. And in future someone is quite likely to need cfun to dump something new too. At the same time, re-implementing dumping c-family/c-gimplify.c:c_genericize when dump_function suffices seems ugly to me. So I am going to declare dump_function a front-end interface and use set_cfun in my original patch in dump_function_to_file like we do in other such functions. I hope that will be OK. Thanks, Martin PS: Each of various alternatives proposed in this thread had someone who opposed it. If there is a consensus that some of them should be implemented anyway (like global value profiling hash), I am willing to do that, I just do not want to end up bickering about the result.
