[macstl-dev] gcc 3.3 on YellowDogLinux

[Glen Low]

On 28/03/2005, at 8:59 PM, Michael LeBlanc wrote:

> That almost works.  I think I never tried removing the outer ()-s.  
> I'm using
>
>                 typedef __vector unsigned int generator_returns;
>
>                 template <unsigned int v0, unsigned int v1, unsigned 
> int v2, unsigned int v3>
>                 struct generator
>                     {
>                         generator_returns
>                         operator() () const
>
> Cross your fingers.  I think that leaves one issue!

Excellent.

>
> /usrb/leblanc/macstl/macstl/impl/vec_altivec.h: In function `
>    macstl::vec<unsigned int, 4> 
> macstl::altivec::impl::estimate_divide(const
>    macstl::vec<unsigned int, 4>&, const macstl::vec<unsigned int, 
> 4>&)':
> /usrb/leblanc/macstl/macstl/impl/vec_altivec.h:1263: error: conversion 
> from `
>    const macstl::vec<int, 4>' to non-scalar type `
>    macstl::vec<macstl::boolean<int>, 4>' requested
>
> This, and others like it, are caused by my "fencing" a few bool 
> things.  Recall that GCC stomps on the keyword bool in altivec.h by 
> making it a macro.
>
> #ifndef MACSTL_BOOL_IS_SIGNED
>                 template <> struct data_vec <__vector bool char>       
>  { typedef vec <boolean <char>, 16> type; };
>                 template <> struct data_vec <__vector bool short>      
>  { typedef vec <boolean <short>, 8> type; };
>                 template <> struct data_vec <__vector bool int>        
>  { typedef vec <boolean <int>, 4> type; };
>                 template <> struct data_vec <__vector pixel>           
>  { typedef vec <pixel, 8> type; };
> #endif

Side point: does stomping on the C++ reserved word bool mean that 
altivec.h is useless for C++ work?

Line 1263 is a mule or mulo function call, unlikely that it would 
involve data_vec. Instead I use some SFINAE techniques to automatically 
make the function mule or mulo parallel the types of the inbuilt 
vec_mule and vec_mulo, so you might have to do a bit more fencing. Look 
at line 1006 onwards for example. The type_to_kind and kind_to_type 
functions assume a 1-1 mapping between native types and vec wrappers; 
if this is no longer true (since e.g. __vector signed int corresponds 
to both vec <int, 4> and vec <boolean <int>, 4>), we might have to work 
a bit harder to maintain the relationship.

Is there any way, perhaps using a command-line switch or equivalent, to 
keep the old Motorola style definition of bool?


Cheers, Glen Low


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