This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] - Fix PR 21956 and PR 22003
- From: Steven Bosscher <stevenb at suse dot de>
- To: gcc-patches at gcc dot gnu dot org
- Cc: Richard Henderson <rth at redhat dot com>, Caroline Tice <ctice at apple dot com>, "gcc-patches at gcc dot gnu dot org Patches" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 27 Jul 2005 02:25:03 +0200
- Subject: Re: [PATCH] - Fix PR 21956 and PR 22003
- References: <0ec3a4d7b3e65f1120265fccecbd2dc1@apple.com> <20050628234700.GA19409@redhat.com>
On Wednesday 29 June 2005 01:47, Richard Henderson wrote:
> On Tue, Jun 28, 2005 at 04:09:17PM -0700, Caroline Tice wrote:
> > This patch fixes PR 22003 and PR 21956. In PR 22003, I called two
> > macros that assumed
> > cfun->cfg was defined; this failed in a C++ case where the function
> > body was empty.
>
> That's surprising. That sounds like a bug for Jan. We should
> *always* have a cfg, and always have at least one basic block,
> even if that one block is empty.
What happens is this:
assemble_start_function (thunk_fndecl, fnname);
targetm.asm_out.output_mi_thunk (asm_out_file, thunk_fndecl,
fixed_offset, virtual_value, alias);
assemble_end_function (thunk_fndecl, fnname);
This is from cp/method.c:use_thunk(). There doesn't appear to be a
body for these thunks, at least not on that tree_lowering_passes can
handle without ICEing. Should there be an artificial basic block
just to satisfy assemble_start_function? What about an extra flag
for assemble_start_function that it is not outputing the start of a
"normal" function??
Gr.
Steven
P.S. Caroline, do you know what partition does the thunk go in when
doing hot/cold partitioning?