This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH: Fix 20000724-1.c


On Mon, Apr 30, 2001 at 07:59:41AM -0700, Mark Mitchell wrote:
> 
> This test was nominally a regression from GCC 2.95.x.
> 
> The problem was that our code to combine stack-adjustments moves an
> adjustment across a call expressed as inline assembly, essentially
> putting a variable out of scope sooner that it should.
> 
> In looking at it carefully, I think the extended asm is bogus.  In
> particular, we have:
> 
>   !   asm volatile("call ___checkme" : : "c" (x) : "memory");
> 
> where `__checkme' is a function which fiddles around with the stack.
> The asm doesn't clobber the stack pointer, which is wrong; GCC has no
> way to know that this instruction messes with that register.

It leaves the register the same as it used to be before.
The actual regression this test shows was seen initially in the Linux kernel
(do_asm was a down and the stack clobbering was because of an interrupt
handler - down was given a semaphore on the local function stack, but before
the asm volatile the stack was adjusted; everything below stack pointer on
STACK_GROWS_DOWNWARDS machines has to be considered volatile).
Changing the test just hides the fact that this is not fixed.

In gcc-2.96-RH I'm using a hack for this:

--- gcc/regmove.c.jj    Mon Jul 24 11:54:38 2000
+++ gcc/regmove.c       Tue Jul 25 00:05:00 2000
@@ -2328,6 +2328,16 @@ combine_stack_adjustments_for_block (bb)
       if (! INSN_P (insn))
        goto processed;

+      if (asm_noperands (PATTERN (insn)) >= 0)
+       {
+         /* Asm might be given just a pointer to some local stack area.  */
+         free_csa_memlist (memlist);
+         memlist = NULL;
+         last_sp_set = NULL_RTX;
+         last_sp_adjust = 0;
+         goto processed;
+       }
+
       set = single_set_for_csa (insn);
       if (set)
        {

which fixed the kernel miscompilation, but Jan had a better fix which has
been floating around on gcc-patches (basically his patch when merging two
stack adjustements if they both were in the same direction has combined them
into the first instruction's location if they subtracted from stack pointer
and into the last instruction's location if they added to the stack pointer
(speaking about STACK_GROWS_DOWNWARDS, otherwise the other way around)).

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]