So now the job of the package maintainer is to work out what that actually
means, and fix the problems.

If you need an account on a PPC machine, please let me know.

(In reply to comment #1)
> If you need an account on a PPC machine, please let me know.
That would be useful, I have several other packages that are
excluded for ppc.
If I cannot find the problem with a reasonable effort, I will
have to notify and leave it to upstream, though.

Did you ever take me up on this offer? Mail me a SSH public key and I'll set you
up an account.

Three of the differences are only in timing, which seems perfectly reasonable.
The only one which looks like it's a real problem is graph-dyn.dif:

 *** psplothraw: bug in GP (Segmentation Fault), please report

? psplothraw(vector(100,k,k),vector(100,k,k*k/100))

Program received signal SIGSEGV, Segmentation fault.
gtodblList (data=0xfeabef44, flags=1) at ../src/graph/plotport.c:1183
1183      lx1 = lg(data[1]);
(gdb) bt
#0  gtodblList (data=0xfeabef44, flags=1) at ../src/graph/plotport.c:1183
#1  0x44002484 in ?? ()
#2  0x10016e68 in plothraw0 (stringrect=16, drawrect=17, listx=0xf7fe0768, 
    listy=0xf7fe0118, flags=524352) at ../src/graph/plotport.c:1759
#3  0x0fe6f63c in truc () at ../src/language/anal.c:2175
#4  0x24000484 in ?? ()
#5  0x0fe70880 in facteur () at ../src/language/anal.c:1312
#6  0x24000484 in ?? ()
#7  0x0fe70bf4 in expr () at ../src/language/anal.c:848
#8  0x24000484 in ?? ()
#9  0x0fe723b0 in seq () at ../src/language/anal.c:798
#10 0x0fe72e5c in gpreadseq (
    c=0x100a91f8 "psplothraw(vector(100,k,k),vector(100,k,k*k/100))", 
    strict=32) at ../src/language/anal.c:468
#11 0x10009548 in gp_main_loop (ismain=1) at ../src/gp/gp.c:1462
#12 0x1000a7a0 in main (argc=1, argv=0xfeabf5b4) at ../src/gp/gp.c:1863

This code is just plain broken. Look at the preprocessed output of the
plothraw0() function:

static GEN
plothraw0(long stringrect, long drawrect, GEN listx, GEN listy, long flags)
{
  PARI_plot *output = init_output(flags);
  long data[] = {(((ulong)(t_VEC)) << ((1L<<(2 +3)) - 7)) | (3), 0, 0};
  dblPointList *pl;

  (((GEN*) (data))[1]) = listx;
  (((GEN*) (data))[2]) = listy;
  pl=gtodblList(data,0x00001);
  if (!pl) return cgetg(1,t_VEC);
  return rectplothrawin(stringrect,drawrect,pl,flags | 0x00001,output);
}


How this _ever_ works without -fno-strict-aliasing I cannot comprehend, but it
doesn't seem to be PPC-specific. The compiler is perfectly entitled to optimise
away the assignments to data[1] and data[2], and it seems to have done so.

Adding '-fno-strict-aliasing' to CFLAGS when building gp seems to fix the problem.

In comment #2 you say you "have several other packages which are excluded on
ppc". What are they, and shouldn't they be blocking bug #179260?

I added the -fno-strict-aliasing flag and disabled the check (because of the
failures due to timing).

As far as I can tell, you didn't need to disable the check -- it didn't actually
cause the RPM build to fail. I think maybe the timing differences only get
reported when there was a real failure too.

Thanks.