This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix PR29254 (cgraph, P1)
- From: Roger Sayle <roger at eyesopen dot com>
- To: Richard Guenther <rguenther at suse dot de>
- Cc: Jan Hubicka <jh at suse dot de>, <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 9 Oct 2006 10:27:28 -0600 (MDT)
- Subject: Re: [PATCH] Fix PR29254 (cgraph, P1)
On Mon, 9 Oct 2006, Richard Guenther wrote:
> This patch fixes an ICE-after-error (still P1...) by not verifying
> the cgraph in that case (which is what other entries into that code do).
After carefully reading Jan's postings and comments on the issue, I
believe your patch is the correct fix. We seem to oscillate back and
forth over whether we should "firewall" errorcount/sorrycount at
tree_rest_of_compilation, but it appears the current thinking is to
proceed through tree_rest_of_compilation (for the benefit of cgraph)
and carefully gate the passes in all_passes to prevent things
like error_mark_node reaching most of the middle-end. For example,
gate_rest_of_compilation prevents us running the RTL optimizers on
errors, and gate_all_optimizations prevents us from running the
Given this plan, adding the check to verify_cgraph_node (which matches
the similar test in verify_cgraph) is the appropriate fix.
Ideally, it would be nice to document this current design philosophy
somewhere (perhaps above tree_rest_of_compilation and/or before the
construction of all_passes in init_optimization_passes). For example,
it looks like we can execute pass_expand_omp when sorrycount != 0,
and always perform RTL expansion even in the presence of parsing
errors and -fsyntax-only. These are probably safe, but possibly
inefficient, and potentially unanticipated.
PRs like 29254 can be avoided/reduced if we document that functions
like verify_cgraph_node may be called in the presence of errors (the DMZ
between the front-end and the middle-end). Another example is that we
always run the fixupcfg pass, but can't always check that it did its job
correctly as calling verify_cfgraph afterwards is sometimes a no-op. :-)
It might make sense that if we do some subset of cgraph processing after
errors, that the corresponding verify_* routines check the invariants
of that subset afterwards.
> 2006-10-09 Richard Guenther <email@example.com>
> PR middle-end/29254
> * cgraphunit.c (verify_cgraph_node): Bail out on earlier
> * gcc.dg/pr29254.c: New testcase.
This is OK for mainline. Thanks.