[macstl-dev] gcc 3.3 on YellowDogLinux

[Michael LeBlanc]

On Mar 23, 2005, at 6:56 PM, Glen Low wrote:

> On 24/03/2005, at 4:56 AM, Michael LeBlanc wrote:
>
>> Folks, I am extremely new to macstl.  I get zillions of compile-time 
>> errors building a simple test.  Am I expecting too much?
>
> Not at all. I don't have a Linux box handy but would love to get 
> macstl to work with Linux, if you're willing to be the guinea pig. :-)

I volunteer.  Although our hardware is not Mac, it's PPC G4 running YDL 
3.0.  The OS comes with GCC 3.2.2.  We build 3.3 configured with 
--enable-altivec.

> The first lot of errors looks to me that mainline gcc isn't defining 
> the vector types as distinct C types, you might need to check 
> altivec.h for this, or try compiling this simple test:
>
> __vector signed char x;
> __vector bool char y = x;

It compiles OK.  And, yes, I have to prepend #include <altivec.h> which 
contains

   #define bool signed
   #define pixel unsigned short
   #define __pixel unsigned short

>> Another concerns these lines in the same header:
>>
>> template <unsigned int v0, unsigned int v1, unsigned int v2, unsigned 
>> int v3> struct generator
>>    {
>>       __vector unsigned int operator() () const
>>
>> The error message is:
>>
>> /home/leblanc/MACSTL/macstl/macstl/impl/vec_altivec.h:59: sorry, 
>> unimplemented: `
>>    integer_cst' not supported by dump_type
>
> There are two ways of initializing native vector types, one way looks 
> like C99 array initialization so I call the macro that controls it 
> "USE_C99_VEC_INIT_IN_TEMPL"; the other way looks like C++ 
> initialization and comes from Motorola, so I call that 
> "USE_MOT_VEC_INIT_IN_TEMPL".

The first was being #define-d.  Now they are both #undef-d, but I still 
get the same error.