This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Altivec context-sensitive keywords (round 2)
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: bje at au1 dot ibm dot com (Ben Elliston)
- Cc: pinskia at gmail dot com (Andrew Pinski), gcc-patches at gcc dot gnu dot org (gcc-patches), dje at watson dot ibm dot com, janis187 at us dot ibm dot com
- Date: Fri, 25 Jul 2008 18:56:21 +0200 (CEST)
- Subject: Re: PATCH: Altivec context-sensitive keywords (round 2)
Ben Elliston wrote:
> I'm not sure there is anything undesirable about this. Is "vector bool"
> an explicitly invalid Altivec type?
No, "vector bool" is valid, and it is handled correctly by the current
(pre-define) method *if* you include <altivec.h>. In fact, if you
include <altivec.h>, "__vector bool" and "__vector __bool" are also
handled.
The problem comes if you do *not* include <altivec.h> (which corresponds
more-or-less to using -std=c99 with the new context-sensitive method).
In this situation "__vector __bool" is still handled, and "vector bool"
is rejected because "vector" is not recognized.
However, the special case "__vector bool" causes problems, because
__vector identifies an AltiVec vector, but "bool" in this case is the
normal C++ boolean type, *not* the AltiVec bool type. Therefore, the
back-end is asked to construct an AltiVec vector with a non-AltiVec
element type, which is rejected.
However, this seems to me to be an artifact of the pre-define method
in the absence of the <altivec.h> header. With the context-sensitive
method, accepting "__vector bool" seems to be the correct thing to do.
Of course, this means the test case should be fixed. As the test case
explicitly does not include <altivec.h>, it probably should simply
use the -std=c99 option with the context-sensitive method?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com