This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
-mabi=altivec have?

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:
Professional Gypsy Lost in Australia
Red Hat, Inc.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]