[macstl-dev] gcc 3.3 on YellowDogLinux

[Glen Low]

On 24/03/2005, at 9:03 PM, Michael LeBlanc wrote:

>
> 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.

Great! macstl should be a good fit for you guys, because it's trig and 
transcendental function implementation is independent of Apple's 
vecLib.

>
>> 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

At the very least the first #define is problematic for pure C++ code 
since bool is a reserved word. Is that particular #define fenced in any 
way? I suggest adding a #ifdef test for mainline gcc and non-Apple code 
in config.h, then #define'ing several conditions that can be used in 
the actual code e.g. the way I did #define USE_MOT_VEC_INIT_IN_TEMPL. 
You can then fence the appropriate definitions of data_vec with the 
condition.

>
>>> 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.

Hmmm, where exactly is the error occurring? A few things you could try:

in the struct generator, do a typedef of __vector unsigned int, and let 
the operator() have that as the return type. Some of the compilers have 
difficulty parsing the __vector constructs especially with complicated 
C++ expressions, Apple's done a stellar job with Apple gcc but 
obviously not all the patches have been returned to mainline.

Try changing it to just int to see if the compiler will get past that 
line.

Cheers, Glen Low


---
pixelglow software | simply brilliant stuff
www.pixelglow.com
aim: pixglen