Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 193727
Summary: | Build on ppc fails some tests during the %check phase | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Gérard Milmeister <gemi> |
Component: | pari | Assignee: | Gérard Milmeister <gemi> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 5 | CC: | extras-qa |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | powerpc | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-12-29 17:51:44 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 179260 |
Description
Gérard Milmeister
2006-05-31 21:17:22 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. (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. |