[macstl-dev] gcc 3.3 on YellowDogLinux
Glen Low
glen.low at pixelglow.com
Wed Mar 30 08:43:40 WST 2005
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
More information about the macstl-dev
mailing list