[macstl-dev] Re: gcc-4.0.0 la perfecto!

[Ilya Lipovsky]

On Fri, 1 Jul 2005, Glen Low wrote:

> On 01/07/2005, at 7:37 AM, Ilya Lipovsky wrote:
>
>> ... were almost :) ... Besides, I don't know if it's in Italian or Spanish.
>> 
>> Anyway, gcc-4.0.0 seems to take care of the previous horrors while 
>> introducing only minimal issues some of which, I must say, should be 
>> attributed to the programmer's side rather than to the capriciousness of 
>> the compiler.
>
> Excellent (except for that subtle dig at the "programmer's side" :-) ). The 
> data_type typedef issue is weird, although I know gcc usually has issues 
> typedef'ing its type attributes inside of a template. One last thing before 
> we abandon FSF gcc 3.4.2 -- if you change from
>
> typedef __vector unsigned char data_type
>
> to
>
> typedef unsigned char data_type __attribute__ ((vector_size (16))
>
> Does it now compile OK on gcc 3.4.2?
>

Hate to disappoint you: it didn't work. I tried several combinations of 
positioning the attribute and also using it together with __vector -- all 
just to make sure, but it did not succeed in resolving the same old:

../emu/macstl/sml_valarray/macstl/impl/vec_altivec.h: In static member 
function `static macstl::vec<unsigned char, 16u> macstl::vec<unsigned 
char, 16u>::fill(
unsigned char)':
../emu/macstl/sml_valarray/macstl/impl/vec_altivec.h:364: error: no 
matching function for call to `vec_splat(unsigned char&, int)'
/usr/gcc-3.4.2/lib/gcc/powerpc-unknown-linux-gnu/3.4.2/include/altivec.h:4752: 
note: candidates are: ........................ blah-blah-blah

>> 
>> So here's the set of corrections you need to perform to make stuff 
>> compilable properly:
>> 
>> 1) Fix the issue with absence of newline character at the end of some 
>> files.
>> 
>> 2) In valarray_altivec.h add to the beginning:
>> 
>> #ifdef __linux__
>> extern "C" void *memalign (size_t boundary, size_t __size);
>> #endif
>
> Where is the typical header for memalign located -- then we can #include that 
> instead.

The header file to be included for memalign to be prototyped properly is:

malloc.h

which is a part of glibc and not the compiler itself, I believe.


>
>> 3) Hairy issue: in gslice.h make the following changes:
>> 
>> on line 124 change:
>> 
>> if (++(indexer_ [dim - 1]) != lengther_ [dim - 1])
>> 
>> into:
>> 
>> indexer_ [dim - 1] = indexer_ [dim - 1]+1; if (indexer_ [dim - 1] != 
>> lengther_ [dim - 1])
>> 
>> and on line 151:
>> 
>> --(indexer_ [dim - 1]);
>> 
>> into:
>> 
>> indexer_ [dim - 1] = indexer_ [dim - 1] - 1;
>> 
>> Since, the compiler could not find the operators -- and ++ .
>
> Weird, but OK I will do that.
>
Yeah, I empathetically node with you... I don't get the whole deal either.

>> 4) In file vec_altivec.h correct line 1507 from:
>> 
>> altivec::add (data_cast <vec <unsigned int, 4> > (reciprocal (altivec::ctf 
>> <0> (divisor))), (vector unsigned int) (1 << 28))));
>> 
>> to:
>> 
>> altivec::add (data_cast <vec <unsigned int, 4> > (reciprocal (altivec::ctf 
>> <0> (divisor))), (__vector unsigned int) {1 << 28})));
>> 
>> (Notice the curly brackets around "1 << 28" and the "__" for "__vector")
>
> You should change (vector unsigned int) (1 << 28) to
>
> vec <unsigned int, 4>::fill <1 << 28> ()
>
> since I was supposed to weed out all uses of vector initialization and stick 
> them within the generator.
>

Yes, my bad: it should indeed be changed into vec <unsigned int, 4>::fill 
<1 << 28> ().

> (BTW, if 1 << 28 can't be parsed as a left shift within a template param, 
> just substitute the actual value of 1 << 28 there.
>
No need for that. The above worked fine.

>> Also, on line 1529 correct:
>> 
>> vector unsigned int sixteen = vec_splat_u32 (-16)
>> 
>> into:
>> 
>> __vector unsigned int sixteen = vec_splat_u32 (-16);
>
> Ditto above, where vec_splat_u32 is vec <unsigned int, 4>::fill <???> ()
>
Not exactly, ditto:

vec <unsigned int, 4> sixteen = vec_splat_u32 (-16);

works fine.


>> SUMMARY: That is it - I haven't found anything else for now. This + the 
>> Makefile will get MacSTL going on YDL.
>
> Thanks. It would probably be simpler if you apply your changes as above, 
> create the directory + makefile and just email the zip of the lot back to me 
> privately and I'll update macstl with it. Better still if you can just submit 
> a diff file that I can patch straight in.
>
> As for the complex conjugate I'll apply that change after the changes above, 
> so that the Subversion history looks clean.
>

Ok

-Ilya