[macstl-dev] gcc 3.3 on YellowDogLinux

[Glen Low]

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. :-)
>
> <---------- make your window this wide 
> --------------------------------------------------------------->
>
> One sort from impl/vec_altivec.h complains that the 2nd redefines the 
> 1st:
>
> template <> struct data_vec <__vector signed char>      { typedef vec 
> <signed char, 16> type; };
> template <> struct data_vec <__vector bool char>        { typedef vec 
> <boolean <char>, 16> type; };

Hmmm... are you targeting PowerPC/Altivec on Linux (I'm assuming from 
your use of YellowDog and __vector)? gcc on that platform may require 
using the -maltivec switch instead of Apple's -faltivec switch, and 
#including <altivec.h>. 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;

The above won't compile on Apple gcc since they are distinct types, but 
perhaps not on mainline gcc? I recall seeing some discussion in 
gcc.gnu.org about making the bool types equivalent to the signed types. 
It is generally OK to comment out a couple of data_vec declarations 
since they are to guide the compiler in doing conversions between the 
native vector types and the object-oriented vec types -- if the type 
system isn't strong e.g. with MMX, there's not much that can be done.

> 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". Quite possibly the library is choosing the 
wrong syntax for your compiler. (I think mainline gcc is 
USE_C99_VEC_INIT_IN_TEMPL, which is #defined in impl/config.h)

Additionally USE_MOT_VEC_INIT_IN_TEMPL requires that the compiler 
realize its parameters are constant, and most Motorola-respecting 
compilers don't for template non-type parameters. *sigh* So it's OK for 
both to be undefined, and the library will use a conservative load from 
a static constant.

> That's all for now.  Thanks.

Hope that's enough to get you started. When you get it work 
successfully, I'd appreciate a diff for the changes (although you'll 
have to acknowledge a CLA).

Cheers, Glen Low


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