Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Thu, 28 Feb 2002 16:39:12 +1100
> Cc: kumar.gala@motorola.com, degger@fhm.edu, gcc@gcc.gnu.org,
>    dje@watson.ibm.com
> From: Aldy Hernandez <aldyh@redhat.com>
> 
> >>> No, don't do that.  I can think of lots of reasons not to.
> >>
> >> care to share?
> >
> > You'd be deleting a feature, and worse, you'd be re-using the obvious
> > choice for the option that enables that feature for something
> > different, making it difficult to re-introduce that feature in future.
> 
> a feature that no one would use.
> 
> the same people who would want to link old code, wouldn't be able
> to write code that use varargs, vector arguments, etc, which is
> the reason for -mabi=altivec in the first place.
> 
> in other words, if you DONT use -mabi=altivec, you won't be able
> to use features XYZ.  so it's just the same to imply -mabi=altivec
> from just -maltivec, and have the user just not use features
> XYZ if they want to link in old code.
> 
> basically, there's no added benefit from using a separate
> -mabi=altivec flag, especially if the user claims to know what
> they are doing... in which case they achieve the same functionality
> by not using varargs, vector arguments, etc.

Why can't varargs and vector arguments be supported under the SVR4
ABI?

Isn't altivec still useful even if you can't pass vectors as
arguments?

The significant change that -mabi=altivec makes is that it expects
called procedures to save the call-saved altivec registers.  Thus, you
can't call any non-altivec-abi procedures from an altivec-abi
procedure safely.

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