public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/30254]  New: Need method to determine if AltiVec PIM is available
@ 2006-12-18 19:59 iano at apple dot com
  2006-12-18 20:05 ` [Bug c/30254] " pinskia at gcc dot gnu dot org
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: iano at apple dot com @ 2006-12-18 19:59 UTC (permalink / raw)
  To: gcc-bugs

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


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2010-07-20 14:08 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-12-18 19:59 [Bug c/30254] New: Need method to determine if AltiVec PIM is available iano at apple dot com
2006-12-18 20:05 ` [Bug c/30254] " pinskia at gcc dot gnu dot org
2006-12-18 20:06 ` pinskia at gcc dot gnu dot org
2006-12-18 20:07 ` [Bug target/30254] " pinskia at gcc dot gnu dot org
2006-12-18 20:24 ` iano at apple dot com
2006-12-18 20:53 ` iano at apple dot com
2007-01-07  0:51 ` pinskia at gcc dot gnu dot org
2010-07-20 14:08 ` steven at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).