This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: fix execute/20020412-1.c
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: rth at redhat dot com (Richard Henderson)
- Cc: joern dot rennecke at superh dot com, gcc-patches at gcc dot gnu dot org
- Date: Tue, 17 Sep 2002 00:00:40 -0400 (EDT)
- Subject: Re: fix execute/20020412-1.c
> On Wed, Sep 04, 2002 at 08:22:21PM +0100, Joern Rennecke wrote:
> > I'm not sure if store_one_arg is wrong here - it passes as
> > alignment PARM_BOUNDARY. This is the correct as alignment
> > of the 8 byte slot where the argument is passed, but it is not the
> > alignment of the place where the struct tiny is actually stored.
>
> Is this fixed by
>
> http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00972.html
>
> if you remove the #ifdef ARGS_GROW_DOWNWARD around
> the FUNCTION_ARG_PADDING check?
Yes, I believe it would. The case I was working on had ARGS_GROW_DOWNWARD
defined and that's where I added the pad_below code in function.c. However,
essentially the same code is present in function.c for the case where
ARGS_GROW_DOWNWARD is not defined. So, I suspect that using alignment
PARM_BOUNDARY could cause unaligned code to be generated on systems
that don't define ARGS_GROW_DOWNWARD and require downward padding.
I didn't notice that unaligned code was being generated until I tested
the patch under hpux. The linux unaligned trap handler hid the problem.
> Additionally, we should probably be examining SIZE before
> dropping the alignment all the way down to BITS_PER_UNIT.
Yes, the alignment could be 2*BITS_PER_UNIT if SIZE is even. This
probably would give better code for this case.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)