[macstl-dev] gcc 3.3 on YellowDogLinux

Glen Low glen.low at pixelglow.com
Fri Mar 25 08:47:46 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 24/03/2005, at 11:12 PM, Michael LeBlanc wrote:

> I tried to cut the problem down to size.  It looks like __vector is 
> being dropped from the return type of operator().  When using an 
> explicit type, it draws the weird error.
>
> $ cat -n y.cpp
>      1  #include <altivec.h>
>      2
>      3  template <unsigned int v0> struct generator
>      4      {
>      5  #ifdef USE_TYPEDEF
>      6      typedef __vector unsigned int T;
>      7      T
>      8  #else
>      9      __vector unsigned int
>     10  #endif
>     11      operator() () const
>     12          {
>     13          union union_type
>     14              {
>     15              unsigned int val [4];
>     16              __vector unsigned int vec;
>     17              };
>     18          static const union_type un = {v0, v0, v0, v0};
>     19          return un.vec;
>     20          }
>     21      };
>     22
>     23  __vector unsigned char zz =
>     24      static_cast <__vector unsigned char>
>     25      (generator <0> () ())
>     26      ;
>     27
>
> $ gcc -c y.cpp
> y.cpp:12: sorry, unimplemented: `integer_cst' not supported by 
> dump_type
> y.cpp:25: error: non-template type `generator' used as a template
>
> $ gcc -c y.cpp -DUSE_TYPEDEF
> y.cpp:25: error: invalid static_cast from type `unsigned int' to type 
> `vector
>    unsigned char'
> y.cpp: In member function `unsigned int generator<v0>::operator()() 
> const [with
>    unsigned int v0 = 0]':
> y.cpp:25:   instantiated from here
> y.cpp:19: error: cannot convert `vector unsigned int' to `unsigned 
> int' in
>    return

Totally weird is right. Looks like the mainline gcc Altivec parser is 
seriously, um, buggered.

Try declaring the typedefs outside of a class. I sometimes find gcc is 
a little silly about its C extensions scoped within a C++ class (e.g. I 
tried the no_alias attribute but it caused ICE's and other 
unpleasantness if used in a typedef scoped within a C++ class). Try 
within a namespace (stdext::impl) first, and if that fails, declare 
them at global scope.

If that fails, I'd suggest doing some typedefs with the gcc inbuilt 
vector types e.g.

typedef int v4si __attribute__ ((mode(V4SI)));

and see if that will work. We can fence the declarations appropriately 
for Apple gcc and mainline gcc if it comes to that.

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