This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: 3.3: IA64 bug fixes
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Zack Weinberg <zack at codesourcery dot com>, gcc-patches at gcc dot gnu dot org, Gabriel Dos Reis <Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr>
- Date: Wed, 17 Dec 2003 11:12:42 -0800
- Subject: Re: 3.3: IA64 bug fixes
- Organization: CodeSourcery, LLC
- References: <87d6aoo3y2.fsf@egil.codesourcery.com> <20031217150233.GU24876@devserv.devel.redhat.com>
- Reply-to: mark at codesourcery dot com
On Wed, 2003-12-17 at 07:02, Jakub Jelinek wrote:
> On Tue, Dec 16, 2003 at 01:20:05PM -0800, Zack Weinberg wrote:
> > 2003-12-05 Mark Mitchell <mark@codesourcery.com>
> >
> > * config/ia64/ia64.h (MUST_PASS_IN_STACK): Define.
>
> Doesn't this one affect binary compatibility?
The default version is:
#define MUST_PASS_IN_STACK(MODE,TYPE) \
((TYPE) != 0 \
&& (TREE_CODE (TYPE_SIZE (TYPE)) != INTEGER_CST \
|| TREE_ADDRESSABLE (TYPE) \
|| ((MODE) == BLKmode \
&& ! ((TYPE) != 0 && TREE_CODE (TYPE_SIZE (TYPE)) == INTEGER_CST \
&& 0 == (int_size_in_bytes (TYPE) \
% (PARM_BOUNDARY / BITS_PER_UNIT))) \
&& (FUNCTION_ARG_PADDING (MODE, TYPE) \
== (BYTES_BIG_ENDIAN ? upward : downward)))))
The IA64 version is:
#define MUST_PASS_IN_STACK(MODE, TYPE) \
((TYPE) != 0 \
&& (TREE_CODE (TYPE_SIZE (TYPE)) != INTEGER_CST \
|| TREE_ADDRESSABLE (TYPE)))
So, the difference is just in the last case, where the mode is BLKmode
and FUNCTION_ARG_PADDING is the same as the endianness. In little
endian IA64 mode, FUNCTION_ARG_PADDING is "upward". Therefore, this
last clause is never true; i.e, on little-endian IA64 the two
definitions of MUST_PASS_IN_STACK are equivalent.
HP-UX is the only big-endian IA64 system.
So, this change only affects HP-UX. On HP-UX, we passed some parameters
*both* in registers and on the stack. That doesn't work, regardless of
whether you're interoperating with HP's C compiler or with GCC itself.
This change only affects previously broken code, which now works.
--
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC