This is the mail archive of the
mailing list for the GCC project.
Re: [TESTCASE] Minimized testcase for AltiVec segfault
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: Geoff Keating <geoffk at redhat dot com>
- Cc: kumar dot gala at motorola dot com, degger at fhm dot edu, gcc at gcc dot gnu dot org, dje at watson dot ibm dot com
- Date: Thu, 28 Feb 2002 16:39:12 +1100
- Subject: Re: [TESTCASE] Minimized testcase for AltiVec segfault
>>> 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.
and as daniel and others have pointed out, having -mabi=altivec
is a bit confusing.
considering what i have just said, what possible use could
another alternative, why don't we have altivec abi enhancements
enabled by default for -maltivec, and then have a -mno-altivec-abi
that looks less intrusive, since the common thing is to have the
altivec abi.-- but i still think i'm right ;-)
Aldy Hernandez E-mail: email@example.com
Professional Gypsy Lost in Australia
Red Hat, Inc.