This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Bug target/14960] -maltivec affects vector return with -mabi=no-altivec
- From: Geoff Keating <geoffk at geoffk dot org>
- To: Hartmut Penner <HPENNER at de dot ibm dot com>
- Cc: aldyh at redhat dot com, gcc-patches at gcc dot gnu dot org, janis187 at us dot ibm dot com, zack at codesourcery dot com
- Date: 20 Apr 2004 15:20:36 -0700
- Subject: Re: [Bug target/14960] -maltivec affects vector return with -mabi=no-altivec
- References: <OFFAE4C0AC.41C781D5-ONC1256E7C.00432E62-C1256E7C.004729FA@de.ibm.com>
Hartmut Penner <HPENNER@de.ibm.com> writes:
> > After looking over the altivec code yesterday, I'm not so sure that
> > enabling the altivec ABI by default was such a good idea. At least,
> > doing so can cause user problems.
>
> > -mabi=altivec does the following:
> > a) Changes stack layout. Params, vars etc. are aligned so that vectors
> > can be stored at 16 byte alignment.
>
> Janis pointed me to an error with varargs :
>
> Function bar has following prototype:
> bar (int, ...);
> and is called with bar (1, vec);
>
> Caller is compiled with -mno-altivec -mabi=no-altivec
> Callee is compiled with -maltivec -mabi=no-altivec
>
> int is passed in register 3.
> Since abi=no-altivec caller passed vector argument in gpr 4 and 5.
> In case of abi=altivec it would be gpr 5 and 6.
> Unfortunately, rs6000_va_arg checks for TARGET_ALTIVEC instead
> of TARGET_ALTIVEC_ABI, that means, that callee expect arg in gpr 5 and 6.
> I did fix that, (checking for TARGET_ALTIVEC_ABI), but this does
> not help, since a vector cannot be loaded from an odd address,
> and gpr 4 and 5 are stored to a stack-location,
> which is not a multiple of 16.
This just means that they cannot be loaded directly into an altivec
register, they must be copied using a temporary (aligned) memory location.
--
- Geoffrey Keating <geoffk@geoffk.org>