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 1278135 - regression in binutils-2.25.1
Summary: regression in binutils-2.25.1
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: binutils
Version: rawhide
Hardware: ppc64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Nick Clifton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: PPCTracker
TreeView+ depends on / blocked
 
Reported: 2015-11-04 17:49 UTC by Than Ngo
Modified: 2016-01-14 12:13 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-01-14 12:13:29 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
ATL_dupMBmm0_4_0_b0.c (157.95 KB, text/plain)
2015-11-05 12:47 UTC, Than Ngo
no flags Details

Description Than Ngo 2015-11-04 17:49:10 UTC
atlas build fails on on ppc64 with following errors:

/usr/bin/ppc64-redhat-linux-gcc  -g -Wa,--noexecstack -fPIC -m64 -DL2SIZE=4194304 -I/builddir/build/BUILD/ATLAS/ppc64_base/include -I/builddir/build/BUILD/ATLAS/ppc64_base/..//include -I/builddir/build/BUILD/ATLAS/ppc64_base/..//include/contrib -DAdd_ -DF77_INTEGER=int -DStringSunStyle -DATL_OS_Linux -DATL_ARCH_POWER7 -DATL_VSX -DATL_AltiVec -DATL_USE64BITS -DATL_GAS_PPC -DATL_AVgcc -m64 -DWALL -DATL_NCPU=4 -DATL_UCLEANM -DATL_UCLEANN -DATL_UCLEANK -DATL_BETA=0 -c -x assembler-with-cpp ATL_dupMBmm0_4_0_b0.c
ATL_dupMBmm0_4_0_b0.c: Assembler messages:
ATL_dupMBmm0_4_0_b0.c:386: Error: junk at end of line: `0'
ATL_dupMBmm0_4_0_b0.c:388: Error: junk at end of line: `0'
ATL_dupMBmm0_4_0_b0.c:3989: Error: junk at end of line: `0'
ATL_dupMBmm0_4_0_b0.c:3991: Error: junk at end of line: `0'
dMakefile:334: recipe for target 'ATL_dupMBmm0_4_0_b0.o' failed
make[8]: *** [ATL_dupMBmm0_4_0_b0.o] Error 1

for more info please take a look at:

http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/4048/2874048/build.log

it seems the upstream patch from https://sourceware.org/ml/binutils/2015-04/msg00395.html caues this issue.

Comment 1 Nick Clifton 2015-11-05 11:59:01 UTC
Hi Ngo,

  Please could you upload the ATL_dupMBmm0_4_0_b0.c for me to examine ?  (I am wondering if the assembler is actually correct, and that the problem is that the ATL_dupMBmm0_4_0_b0.c file is out of date).

Cheers
  Nick

Comment 2 Than Ngo 2015-11-05 12:47:24 UTC
Created attachment 1090050 [details]
ATL_dupMBmm0_4_0_b0.c

Comment 3 Than Ngo 2015-11-05 12:49:38 UTC
it seems the new binutitls handles dctd in different way. This assembler code works fine in 2.25.

                dcbt    0, pfA, 0
                addi    pfA, pfA, 128
                dcbt    0, pfB, 0
                addi    pfB, pfB, 128

Comment 4 Nick Clifton 2015-11-05 17:44:06 UTC
Hi Ngo,

  I am not a PowerPC architecture expert, but it looks to me like the "dcbt 0, pfA, 0" syntax is only valid on some architecture variants, not all of them.  Plus, I think that what happened between 2.25 and 2.25.1 is that the architecture checking for the DCBT instruction was tightened up.

  Hence the problem is that code in ATL_dupMBmm0_4_0_b0.c is being assembled without the correct PowerPC variant being specified on the assembler command line.  (Or maybe no architecture variant is being specified at all, and a default, basic architecture is being used ?).  

  Does this theory make sense ?  If so then maybe adding something like "-Wa,-mpower7" to the gcc command line might act as a workaround ?

Cheers
  Nick

Comment 5 Than Ngo 2015-11-13 14:13:23 UTC
Hi Nick, it seems you are right, the architecture checking for the DCBT instruction was tightened up in new binutils and adding -Wa,-mpower7 to assembler option the above assembler code built correctly.

Comment 6 Than Ngo 2016-01-14 12:13:29 UTC
it seems a bug in atlas. And the issue was fixed in latest atlas


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