[macstl-dev] gcc 3.3 on YellowDogLinux

[Michael LeBlanc]

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

As it is, it clobbers any later use of C++ bool.  See below.

> Line 1263 is a mule or mulo function call, unlikely that it would 
> involve data_vec.

Sorry.  That's 1263 in my hacked up version.

   59 #define MACSTL_VEC_BOOLEAN_INT_4 vec <int, 4>
   60
   61 #ifdef USE_C99_VEC_INIT_IN_TEMPL
   62 # define MACSTL_CAST_SCALAR_TO_VECTOR(typ,val) ((vector typ) {val})
   63 #else
   64 # define MACSTL_CAST_SCALAR_TO_VECTOR(typ,val) ((vector typ) (val))
   65 #endif
....
1263    MACSTL_VEC_BOOLEAN_INT_4 two_minus_divisor_reciprocal_high =
1264        altivec::cmplt (data_cast <vec <int, 4> > 
(divisor_reciprocal_low), MACSTL_CAST_SCALAR_TO_VECTOR(signed int, 1));

I changed all instances of "vec <boolean <int> >, 4>" as above and ... 
your benchmark test compiles and links!  Of course *sigh* it traps at 
run-time.

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

Not that I know of.  After including <altivec.h> I can add
	#undef bool
to unhide the reserved word.  But that clobbers any legitimate "vector 
bool ...".

This is a problem in GCC < 3.4.  In that version, GCC treats vector, 
bool and pixel as Apple does.