[Debian GNUstep maintainers] Bug#893442: lynkeos.app: FTBFS on ppc64el: AltiVec argument passed to unprototyped function

[Frédéric Bonnard]

Hi Yavor,

On Thu, 22 Mar 2018 12:04:33 +0200, Yavor Doganov <yavor at gnu.org> wrote:
> Frédéric Bonnard wrote:
> > I'm not an altivec expert but I was interested to look into this and
> > maybe help.
> 
> Many thanks for taking the time and effort, this is exactly the
> response I was hoping for.
> 
> > When I compile :
> > __vector unsigned char Va = vec_pack(vec_pack(vec_ctu(Vperma, 0), vec_splat_u32(0)), vec_splat_u16(0));
> > __vector unsigned char Vb = vec_pack(vec_pack(vec_ctu(Vpermb, 0), vec_splat_u32(0)), vec_splat_u16(0));
> > 
> > and print those, I have : 
> > Va :  3  3  8  8 0 0 0 0 0 0 0 0 0 0 0 0
> > Vb : 10 10 10 10 0 0 0 0 0 0 0 0 0 0 0 0
> 
> This looks bogus; either a bug in my code or the unfortunate result of
> the type conversion.  Knowing me, I would definitely bet it's the
> former :)
> 
> Out of curiosity, how do you print vectors?  Is there a specific
> function or you write your own?

Good question : I used libvecpf which I linked against.
Then %vf displays the floats and %vlX the hexadecimal representation.

> > So with this :
> > vector unsigned char Va = { 0, 1, 2, 3, 0, 1, 2, 3, 4, 5, 6, 7, 4, 5, 6, 7 };
> > vector unsigned char Vb = { 8, 9, 10, 11, 8, 9, 10, 11, 12, 13, 14, 15, 12, 13, 14, 15};
> > we get the following indexes :
> > Va : 0 1 2 3 0 1 2 3 4 5 6 7 4 5 6 7
> > Vb : 8 9 a b 8 9 a b c d e f c d e f
> > 
> > which extracts good looking floats.
> 
> Thanks, I will use your version of the patch.

Maybe some closer representation to the initaal four hex would be nice
too.

> > I also extracted part of the computation code to test the computation
> > done with some random floats and check if the results make some sense which
> > seems to be the case (in terms of addition, multiplication, load/store).
> > I also did this on powerpc, ppc64 and ppc64el to see if I had some
> > endianness issue, but I got the same results on the 3 archs.
> 
> Thanks for doing this, I was going to ask if it's possible to check
> for endianness bugs as well but thought it would be too pushy.  As
> ppc64el is a relevantly new architecture it's quite common to see code
> assuming big endian (powerpc/pcc64).
> 
> If my grasp of GCC's configuration is correct, this particular snippet
> is conditionally compiled only on ppc64el because -mvsx is the default
> which implies -maltivec.  This is not the case for the other PowerPC
> ports which (should) support machines without AltiVec, so it would be
> a bug in the package if it assumed AltiVec everywhere.

Indeed, I had to pass -maltivec to powerpc and ppc64.

> Anyway, it's good to know that it works as expected on the other
> PowerPC ports.

Well coherency seems preserved at least : either it's all correct on the
3 or it's all false :) .. it needs more test or some knowledge of the
computations done (see below).

> > The best would be to test all this in real by running lynkeos.app's
> > deconvulation, or at least compile part of the original code on Mac
> > OS X and check if the indexes used here gives the same results
> > compared to the original ones.
> 
> I don't have access to Mac OS X and wouldn't want to use it even if I
> had.

:D

> It is natural to ask the upstream author to perform this test
> but his email bounces.  And I never received a response from the
> person who ported the 1.x series to GNUstep.

Pity

> If you have some spare time and direct access to a GNU/Linux PowerPC
> machine, perhaps you can compare the results (visually) with another
> common architecture by processing the same image?  Or on powerpc/ppc64
> with and without AltiVec.

Will try. I feel somehow unsatisfied to have no certainty at this point,
but wanted to give you some feedback early.

F.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnustep-maintainers/attachments/20180322/c55807f6/attachment.sig>