It is possible with most compilers use the __VEC__ symbol to indicate that the
AltiVec C Programming Interface is available. GCC has taken a different track.
It is possible to have __VEC__ defined (-maltivec) without the C Programming
Interface operational (altivec.h has not been included.)
It is difficult to deal with this problem in places like system headers, where
the current compilation environment is not known. On a vector ISA like SSE this
is not a problem. Such system headers can safely include things like
xmmintrin.h as needed to get the types/interfaces they need. Not so with
AltiVec! The addition of several new keywords like vector and bool may cause
ordinary C and C++ programs to fail to compile. We need to know if the user has
turned on the PIM so we know if should use the interface in library/system
headers, where we have no control over the compilation environment.
The current situation is a bit tangly because of -faltivec:
-faltivec: defines __VEC__, defines __APPLE_ALTIVEC__,
does not include altivec.h (on Apple compiler at least)
does not define _AltiVec_H
-maltivec: defines __VEC__, may or may not define __APPLE_ALTIVEC__
depending on GCC version
PIM active status dependent on whether altivec.h is
included.
We don't know if the symbol _AltiVec_H
I'm asking for one of several solutions:
1) Attempt to conform to behavior of other compilers -- only define __VEC__ if
the PIM is on.
I think this would mean that -maltivec does not define __VEC__,
-faltivec does and altivec.h
defines it too
2) Provide a new symbol such as __ALTIVEC__PIM__ that we can test against
3) Fix __APPLE_ALTIVEC__ so that is is defined in some predicable manner that
can be used for this purpose. Perhaps all you need here is a verification test
case. The problem case appears to be the Cell / Linux GNU tool chain, which
defines __APPLE__ALTIVEC__ without -faltivec or include "altivec.h"
Maybe some other way?
--
Summary: Need method to determine if AltiVec PIM is available
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iano at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30254
