This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix emit_library_call_value to not use virtual stack regs after expand
- From: Steven Bosscher <stevenb dot gcc at gmail dot com>
- To: Maxim Kuvyrkov <maxim at codesourcery dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 24 Jun 2009 14:34:59 +0200
- Subject: Re: [PATCH] Fix emit_library_call_value to not use virtual stack regs after expand
- References: <4A4217FE.1060802@codesourcery.com>
On Wed, Jun 24, 2009 at 2:11 PM, Maxim Kuvyrkov<maxim@codesourcery.com> wrote:
> Hello,
>
> The following simple patch [which is just a duplication of a hunk from
> within emit_library_call_value_1] fixes ICE when compiling for m68k/ColdFire
> machines without hardware divide.
>
> The ICE occurs in reload on gcc.c-torture/execute/loop-3b.c test due to
> occurrence of virtual_outgoing_args_rtx in the instruction stream. ?This
> virtual register is used within expand and then is substituted with
> (stack_pointer_rtx + STACK_POINTER_OFFSET) at the end of expand.
>
> Evidently, there still remains a way to generate virtual_outgoing_args by
> the loop optimizer. ?The loop optimizer emits a divide instruction which,
> due to target not having hwdiv, expands into a library call.
>
> emit_library_call_value_1 deals with virtual_outgoing_args_rtx in two
> places: the first already handles case when virtuals are instantiated; this
> patch fixes the second.
>
> Tested by bootstrapping on x86_64. ?OK for trunk?
It was my understanding that the expanders should never be used after
'expand', but to get this libcall you have to go through an expander,
right?
So maybe the bug is in the loop optimizer -- it shouldn't try to do
its transformations if it has to do them via expanders.
Thoughs?
Ciao!
Steven