Bug 193727 - Build on ppc fails some tests during the %check phase
Build on ppc fails some tests during the %check phase
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: pari (Show other bugs)
5
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Gérard Milmeister
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F-ExcludeArch-ppc
  Show dependency treegraph
 
Reported: 2006-05-31 17:17 EDT by Gérard Milmeister
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-29 12:51:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gérard Milmeister 2006-05-31 17:17:22 EDT
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
	number-dyn.dif
	polyser-dyn.dif
	graph-dyn.dif
	nfields-dyn.dif
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 17:29:46 EDT
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 17:52:39 EDT
(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 04:48:21 EDT
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-28 19:50:16 EST
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-28 19:58:51 EST
? 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-28 20:15:29 EST
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?
Comment 7 Gérard Milmeister 2006-12-29 12:51:44 EST
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 13:43:14 EST
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.

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