This is the mail archive of the
mailing list for the GCC project.
Re: mudflap versus cgraph
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org, Frank Eigler <fche at redhat dot com>, Jan Hubicka<jh at suse dot cz>
- Date: Mon, 21 Jun 2004 23:21:58 -0700
- Subject: Re: mudflap versus cgraph
- References: <firstname.lastname@example.org><40D7BE00.email@example.com>
Mark Mitchell <firstname.lastname@example.org> writes:
> Zack Weinberg wrote:
>>mudflap has a pass-ordering conflict which I cannot figure out how
>>to resolve. mudflap_finish() generates and emits a function
>>(calling tree_rest_of_compilation directly) after cgraph_optimize()
>>has been called, which is wrong. But it has to do that, because the
>>set of items to be registered with the mudflap runtime at static
>>construction time is only determined at final assembly output time
>>-- the callers of mudflap_enqueue_decl/mudflap_enqueue_constant are
> I think that's the problem. In the cgraph world, the arbiter of
> what things are needed is cgraph itself. There should be a hook
> that cgraph calls to add additional functions -- after it has
> already decided on everything else.
Right (although there is a concern about later optimization passes
eliminating the need for some variable or (more likely) constant).
But that's way more invasive than I want right now.
> Is this for your IMA fixes? It might be that mudflap has to be
> broken for a while, while IMA gets fixed...
Yeah, it's for IMA. If it's mudflap's turn to be broken for awhile I
don't have a problem with that, but I didn't want to spring it on
people with no notice.