public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* about stack/args growing up/down
@ 2003-05-15 20:30 DJ Delorie
  2003-05-16  5:13 ` Alan Modra
  2003-05-16  6:27 ` Geoff Keating
  0 siblings, 2 replies; 5+ messages in thread
From: DJ Delorie @ 2003-05-15 20:30 UTC (permalink / raw)
  To: gcc


I'm working on g++.dg/abi/param1.C for xstormy16, where the stack
grows up and args grow down.  In this case, expand_call (calls.c:2699)
calculates the address of the outgoing parm block as the lowest
address of the block (virtual-outgoing-args - 128), but
locate_and_pad_parm is giving the args a negative offset, causing gcc
to later put the arg in the wrong place.

For this type of stack, which of the two values (argblock,
arg->offset) is right, and which one is wrong?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: about stack/args growing up/down
  2003-05-15 20:30 about stack/args growing up/down DJ Delorie
@ 2003-05-16  5:13 ` Alan Modra
  2003-05-16  5:29   ` DJ Delorie
  2003-05-16  6:27 ` Geoff Keating
  1 sibling, 1 reply; 5+ messages in thread
From: Alan Modra @ 2003-05-16  5:13 UTC (permalink / raw)
  To: DJ Delorie; +Cc: gcc

On Thu, May 15, 2003 at 04:30:09PM -0400, DJ Delorie wrote:
> 
> I'm working on g++.dg/abi/param1.C for xstormy16, where the stack
> grows up and args grow down.  In this case, expand_call (calls.c:2699)
> calculates the address of the outgoing parm block as the lowest
> address of the block (virtual-outgoing-args - 128), but
> locate_and_pad_parm is giving the args a negative offset, causing gcc
> to later put the arg in the wrong place.
> 
> For this type of stack, which of the two values (argblock,
> arg->offset) is right, and which one is wrong?

hppa32 stack grows up and args down, and argblock is set to the end
of the outgoing parm block (highest address).  You probably want
to look at STACK_POINTER_OFFSET.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: about stack/args growing up/down
  2003-05-16  5:13 ` Alan Modra
@ 2003-05-16  5:29   ` DJ Delorie
  0 siblings, 0 replies; 5+ messages in thread
From: DJ Delorie @ 2003-05-16  5:29 UTC (permalink / raw)
  To: amodra; +Cc: gcc


> hppa32 stack grows up and args down, and argblock is set to the end
> of the outgoing parm block (highest address).  You probably want
> to look at STACK_POINTER_OFFSET.

Doesn't help.  The bug happens while we're still using the virtual
registers, so we haven't gotten to the point where
STACK_POINTER_OFFSET would be used.  Unless I'm misunderstanding how
that part of the code works, which is likely at this point anyway ;-)

Besides, the xstormy16 doesn't set it, so it's zero, which seems like
the right number anyway.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: about stack/args growing up/down
  2003-05-15 20:30 about stack/args growing up/down DJ Delorie
  2003-05-16  5:13 ` Alan Modra
@ 2003-05-16  6:27 ` Geoff Keating
  2003-05-16 17:13   ` DJ Delorie
  1 sibling, 1 reply; 5+ messages in thread
From: Geoff Keating @ 2003-05-16  6:27 UTC (permalink / raw)
  To: DJ Delorie; +Cc: gcc

DJ Delorie <dj@redhat.com> writes:

> I'm working on g++.dg/abi/param1.C for xstormy16, where the stack
> grows up and args grow down.  In this case, expand_call (calls.c:2699)
> calculates the address of the outgoing parm block as the lowest
> address of the block (virtual-outgoing-args - 128), but
> locate_and_pad_parm is giving the args a negative offset, causing gcc
> to later put the arg in the wrong place.
> 
> For this type of stack, which of the two values (argblock,
> arg->offset) is right, and which one is wrong?

I'm fairly sure this used to work, any idea what changed?

-- 
- Geoffrey Keating <geoffk@geoffk.org>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: about stack/args growing up/down
  2003-05-16  6:27 ` Geoff Keating
@ 2003-05-16 17:13   ` DJ Delorie
  0 siblings, 0 replies; 5+ messages in thread
From: DJ Delorie @ 2003-05-16 17:13 UTC (permalink / raw)
  To: geoffk; +Cc: gcc


> I'm fairly sure this used to work, any idea what changed?

Not yet.  I guess I'll try a regression search next and see if it
comes up with anything.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-05-16 17:13 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-15 20:30 about stack/args growing up/down DJ Delorie
2003-05-16  5:13 ` Alan Modra
2003-05-16  5:29   ` DJ Delorie
2003-05-16  6:27 ` Geoff Keating
2003-05-16 17:13   ` DJ Delorie

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).