Bug 193727 - Build on ppc fails some tests during the %check phase
Summary: Build on ppc fails some tests during the %check phase
Alias: None
Product: Fedora
Classification: Fedora
Component: pari
Version: 5
Hardware: powerpc
OS: Linux
Target Milestone: ---
Assignee: Gérard Milmeister
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F-ExcludeArch-ppc
TreeView+ depends on / blocked
Reported: 2006-05-31 21:17 UTC by Gérard Milmeister
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-12-29 17:51:44 UTC

Attachments (Terms of Use)

Description Gérard Milmeister 2006-05-31 21:17:22 UTC
Some tests fail during the %check phase:

+ make dobench
Making dobench in Olinux-ppc
make[1]: Entering directory `/builddir/build/BUILD/pari-2.3.0/Olinux-ppc'
* Testing objets 	for gp-dyn..TIME=5
* Testing analyz 	for gp-dyn..TIME=76
* Testing number 	for gp-dyn..BUG [52]
* Testing polyser 	for gp-dyn..BUG [20]
* Testing linear 	for gp-dyn..TIME=27
* Testing elliptic 	for gp-dyn..TIME=44
* Testing sumiter 	for gp-dyn..TIME=43
* Testing graph 	for gp-dyn..BUG [19]
* Testing program 	for gp-dyn..TIME=31
* Testing trans 	for gp-dyn..TIME=169
* Testing nfields 	for gp-dyn..BUG [209]
+++ [BUG] Total bench for gp-dyn is 527

PROBLEMS WERE NOTED. The following files list them in diff format: 
Directory: /builddir/build/BUILD/pari-2.3.0/Olinux-ppc
make[1]: *** [dobench] Error 1
make[1]: Leaving directory `/builddir/build/BUILD/pari-2.3.0/Olinux-ppc'
make: *** [dobench] Error 2

Comment 1 David Woodhouse 2006-05-31 21:29:46 UTC
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.

Comment 2 Gérard Milmeister 2006-05-31 21:52:39 UTC
(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.

Comment 3 David Woodhouse 2006-09-09 08:48:21 UTC
Did you ever take me up on this offer? Mail me a SSH public key and I'll set you
up an account.

Comment 4 David Woodhouse 2006-12-29 00:50:16 UTC
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

Comment 5 David Woodhouse 2006-12-29 00:58:51 UTC
? 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

Comment 6 David Woodhouse 2006-12-29 01:15:29 UTC
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;
  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?

Comment 7 Gérard Milmeister 2006-12-29 17:51:44 UTC
I added the -fno-strict-aliasing flag and disabled the check (because of the
failures due to timing).

Comment 8 David Woodhouse 2006-12-29 18:43:14 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.