Red Hat Bugzilla – Bug 1278135
regression in binutils-2.25.1
Last modified: 2016-01-14 07:13:29 EST
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: *** [ATL_dupMBmm0_4_0_b0.o] Error 1
for more info please take a look at:
it seems the upstream patch from https://sourceware.org/ml/binutils/2015-04/msg00395.html caues this issue.
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).
Created attachment 1090050 [details]
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
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 ?
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.
it seems a bug in atlas. And the issue was fixed in latest atlas