This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: altivec questions
- From: Ziemowit Laski <zlaski at apple dot com>
- To: Janis Johnson <janis187 at us dot ibm dot com>
- Cc: gcc at gcc dot gnu dot org, aldyh at redhat dot com
- Date: Wed, 30 Jun 2004 15:45:59 -0700
- Subject: Re: altivec questions
- References: <20040629205816.GA6614@us.ibm.com>
On 29 Jun 2004, at 13.58, Janis Johnson wrote:
Some AltiVec observations and questions:
1. vector bool
The documentation says "The bool type is deprecated and will be
discontinued in future revisions. Use vector signed instead."
That's a bug in the documentation. 'vector bool ...' types are
first-class
citizens which _must_ be kept distinct from 'vector signed ...' or
'vector unsigned ...'.
Recently, though, Zem added lots of support for vector bool and
except for some apparent oversights it appears to be fully supported
now, along with vector pixel.
Indeed. What are the oversights? :-) I wouldn't mind fixing them,
unless
you have done so in the work you mention below.
2. vector long types
Use of "vector signed long" and "vector unsigned long" isn't
documented, but GCC gives "warning: use of 'long' in AltiVec types
is deprecated; use 'int'". These ought to be hard errors for -m64,
right?
Why?
3. pointers to long and unsigned long
Several tests pass 'long *' or 'unsigned long *' in places where the
Motorola AltiVec PIM does not include those types among the
acceptable arguments. GCC doesn't complain for either -m32 or -m64.
These ought to be errors for -m64, right?
Yes, I think they probably should.
Should GCC's altivec.h
support the ones that are used in the gcc.dg/vmx tests?
I've gone through the Motorola AltiVec PIM and altivec.h comparing the
generic and specific AltiVec operations with the C++ functions and the
C macros. I'm sure these matched up when Aldy was finished, but there
are a lot of inconsistencies since the addition of support for vector
bool and vector pixel. I'm testing a big patch to altivec.h that makes
everything match again, and I'll have a patch to extend.texi to make
the
documentation match what's supported in altivec.h. Before I submit
these I'd like to clear up the questions above and make sure I'm
understanding this stuff correctly.
Great; thanks. Please also take a look at the apple-ppc-branch (which
both
IBM and Apple are currently working on); it is possible that it
contains some
of the fixes you are looking for.
Thanks,
--Zem