[macstl-dev] gcc 3.3 on YellowDogLinux

Glen Low glen.low at pixelglow.com
Wed Mar 30 08:43:40 WST 2005

  • Previous message: [macstl-dev] gcc 3.3 on YellowDogLinux
  • Next message: [macstl-dev] gcc 3.3 on YellowDogLinux
  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]


On 28/03/2005, at 11:13 PM, Michael LeBlanc wrote:

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

One possibility is you might have to turn the denormal handling off, if 
it isn't already off for YDL.

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

Ooo... is there any reason you can't use GCC 3.4 on YDL then?

I would suggest our baseline for YDL and other non-Apple PowerPC Unices 
should be GCC 3.4. Reasons: if we hack macstl to support __vector bool 
int == __vector signed int, we have to support this major difference 
within the same code base, the file vec_altivec.h. Or split it off to 
vec_altivec2.h and be burdened with maintaining two otherwise similar 
files.

Finally having bool #defined to something else is simply unacceptable 
for C++ code e.g. overload resolution and storage will be impacted -- 
see Herb Sutter's Guru of the Week about why C++ needs a bool type -- 
http://www.gotw.ca/gotw/026.htm.


Cheers, Glen Low


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




  • Previous message: [macstl-dev] gcc 3.3 on YellowDogLinux
  • Next message: [macstl-dev] gcc 3.3 on YellowDogLinux
  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the macstl-dev mailing list