On several PPC64 systems, we are seeing the following build failure. /home/garyf/gcc-4.8/wrk/./gcc/xgcc -B/home/garyf/gcc-4.8/wrk/./gcc/ [...] -I/home/garyf/gcc-4.8/src/libgcc/../libdecnumber -DHAVE_CC_TLS -o _gcov_execle.o -MT _g cov_execle.o -MD -MP -MF _gcov_execle.dep -DL_gcov_execle -c /home/garyf/gcc-4. 8/src/libgcc/libgcov.c /tmp/ccqVYRai.s: Assembler messages: /tmp/ccqVYRai.s:63: Error: Unrecognized opcode: `sldi' /tmp/ccqVYRai.s:66: Error: Unrecognized opcode: `srdi' /tmp/ccqVYRai.s:67: Error: Unrecognized opcode: `sldi' /tmp/ccqVYRai.s:73: Error: Unrecognized opcode: `srdi' /tmp/ccqVYRai.s:74: Error: Unrecognized opcode: `sldi' /tmp/ccqVYRai.s:88: Error: Unrecognized opcode: `sldi' The failures above use the gcc-4.8-20120729 snapshot which is based on svn revision 189947. The configure target is: powerpc64-unknown-linux-gnu This was built on a rather old (FC6) system running on a Mac G5, but we have seen it also fail on newer PPC64 systems.
We have determined that we can bypass the failure with the following configure switches: --with-long-double-128 --with-cpu-32=power4 --with-tune-32=power6 --with-cpu-64=power4 --with-tune-64=power6 This binutils email thread may be relevant: http://sources.redhat.com/ml/binutils/2010-07/msg00260.html The assembler that we're using is based on binutils 2.20.51.0.2 which is circa the July, 2010 time frame.
sldi and srdi are both standard PowerPC64 instructions. How did you configure GCC?
(In reply to comment #2) > sldi and srdi are both standard PowerPC64 instructions. > > How did you configure GCC? No special switches. For example, $src/configure \ CFLAGS='-O0 -g3' --prefix=$rls \ --enable-languages='c,c++' \ --enable-checking=yes \ --disable-bootstrap \ --disable-multilib is sufficient to reproduce the failure.
One of target platforms is running RHEL 6.2 on a POWER7 series processor. The binutils RPM is: binutils-2.20.51.0.2-5.28.el6.ppc64
Here is the complete output at the point of a make failure. /home/garyf/gcc-4.8/wrk/./gcc/xgcc -B/home/garyf/gcc-4.8/wrk/./gcc/ -B/home/gar yf/gcc-4.8/rls/powerpc64-unknown-linux-gnu/bin/ -B/home/garyf/gcc-4.8/rls/power pc64-unknown-linux-gnu/lib/ -isystem /home/garyf/gcc-4.8/rls/powerpc64-unknown- linux-gnu/include -isystem /home/garyf/gcc-4.8/rls/powerpc64-unknown-linux-gnu/ sys-include -O2 -O0 -g3 -O2 -O2 -O0 -g3 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - isystem ./include -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -f building-libgcc -fno-stack-protector -fPIC -mlong-double-128 -mno-minimal-toc -I. -I. -I../.././gcc -I/home/garyf/gcc-4.8/src/libgcc -I/home/garyf/gcc-4.8/s rc/libgcc/. -I/home/garyf/gcc-4.8/src/libgcc/../gcc -I/home/garyf/gcc-4.8/src/l ibgcc/../include -I/home/garyf/gcc-4.8/src/libgcc/../libdecnumber/dpd -I/home/g aryf/gcc-4.8/src/libgcc/../libdecnumber -DHAVE_CC_TLS -o _mulvdi3.o -MT _mulvd i3.o -MD -MP -MF _mulvdi3.dep -DL_mulvdi3 -c /home/garyf/gcc-4.8/src/libgcc/lib gcc2.c -fvisibility=hidden -DHIDE_EXPORTS /tmp/cci4OPcY.s: Assembler messages: /tmp/cci4OPcY.s:384: Error: Unrecognized opcode: `srdi' /tmp/cci4OPcY.s:430: Error: Unrecognized opcode: `srdi' /tmp/cci4OPcY.s:481: Error: Unrecognized opcode: `srdi' /tmp/cci4OPcY.s:535: Error: Unrecognized opcode: `srdi'
(In reply to comment #2) > sldi and srdi are both standard PowerPC64 instructions. IBM's "Programming Environments Manual for 64-Bit Microprocessors" lists sldi and srdi as "Simplified Mnemonics". Perhaps using the canonical instructions is a simple resolution to this bug? Shift left immediate sldi rA,rS,n (n < 64) rldicr rA,rS,n,63 – n Shift right immediate srdi rA,rS,n (n < 64) rldicl rA,rS,64 – n,n Additionally, there may be a GAS bug lurking here as well.
We're still running into this build failure on PPC64, using a recent revision of the HEAD version. Is there additional information that is needed to help track down the cause of the build failure?
The following is a transcript of a test I just tried one of my systems where Gary and I have observed this bug. The test appears to show that the gcc provided by Fedora Core 6 does generate "sldi" instructions and the system-provided assembler understands them. So, whatever is causing the build failures that Gary and I see, it is *not* simply a matter of an assembler not supporting the instructions. -Paul {phargrov@fc6 ~}$ cat q.c unsigned long long foo(void) { return 0x00007FFF00000000LLU; } {phargrov@fc6 ~}$ gcc -m64 -O -S q.c {phargrov@fc6 ~}$ cat q.s .file "q.c" .section ".toc","aw" .section ".text" .align 2 .globl foo .section ".opd","aw" .align 3 foo: .quad .L.foo,.TOC.@tocbase .previous .type foo, @function .L.foo: lis 3,0x7fff sldi 3,3,16 blr .long 0 .byte 0,0,0,0,0,0,0,0 .size foo,.-.L.foo .ident "GCC: (GNU) 4.1.2 20070626 (Red Hat 4.1.2-13)" .section .note.GNU-stack,"",@progbits {phargrov@fc6 ~}$ as -a64 -mppc64 q.s [no errors]
Following up on my previous experiment, I tried the same input with the xgcc which is failing to build libdecnumber. If also fails with the 1-line test case: {phargrov@fc6 ~}$ cat q.c unsigned long long foo(void) { return 0x00007FFF00000000LLU; } {phargrov@fc6 ~}$ /usr/local/upc/compiler/bld/./gcc/xgcc -B/usr/local/upc/compiler/bld/./gcc/ -m64 -O ~/q.c /tmp/cctmw5wO.s: Assembler messages: /tmp/cctmw5wO.s:14: Error: Unrecognized opcode: `sldi' Examining stderr when "-v" is passed to the two compilers reveals a KEY difference: {phargrov@fc6 ~}$ gcc -m64 -O -v -c q.c 2>&1 | grep -w as as -a64 -mppc64 -many -V -Qy -o q.o /tmp/ccpjKGBl.s {phargrov@fc6 ~}$ /usr/local/upc/compiler/bld/./gcc/xgcc -B/usr/local/upc/compiler/bld/./gcc/ -m64 -O -v -c ~/q.c 2>&1 | grep -w as /usr/local/upc/compiler/bld/./gcc/as -v -a64 -mcom -many -o q.o /tmp/cctEFZq2.s The difference (other than the use of the built-time wrapper script) is "-mppc64" for the Red Hat built gcc-4.2.1 vs "-mcom" for the 4.8.0 snapshot. The following shows that this flag, not the presence of the wrapper script is the origin of the failure: {phargrov@fc6 ~}$ /usr/local/upc/compiler/bld/./gcc/as -a64 -mcom -many -o q.o q.s q.s: Assembler messages: q.s:14: Error: Unrecognized opcode: `sldi' {phargrov@fc6 ~}$ /usr/local/upc/compiler/bld/./gcc/as -a64 -mppc64 -many -o q.o q.s [no error] {phargrov@fc6 ~}$ /usr/bin/as -a64 -mcom -many -o q.o q.s q.s: Assembler messages: q.s:14: Error: Unrecognized opcode: `sldi' {phargrov@fc6 ~}$ /usr/bin/as -a64 -mppc64 -many -o q.o q.s [no error] So, assuming gas is correct in rejecting 'sldi' and 'srdi' in "common" mode the question becomes, "why is gcc by default specifying a target to the assembler which doesn't support the instructions it is generating?" Of course, if 'sldi' and 'slri' ARE supposed to be supported in "common" mode, then this is a binutils bug.
(In reply to comment #9) > Following up on my previous experiment, I tried the same input with the xgcc > which is failing to build libdecnumber. If also fails with the 1-line test > case: Oops. That should have said "failing to build libgcc2", not "libdecnumber".
It is possible that revision 189908 introduced the 'mcom' change. Index: src/gcc/config/rs6000/rs6000.h =================================================================== --- src/gcc/config/rs6000/rs6000.h (revision 189907) +++ src/gcc/config/rs6000/rs6000.h (revision 189908) @@ -101,17 +101,12 @@ you make changes here, make them also there. */ #define ASM_CPU_SPEC \ "%{!mcpu*: \ - %{mpower: %{!mpower2: -mpwr}} \ - %{mpower2: -mpwrx} \ %{mpowerpc64*: -mppc64} \ %{!mpowerpc64*: %{mpowerpc*: -mppc}} \ - %{mno-power: %{!mpowerpc*: -mcom}} \ - %{!mno-power: %{!mpower*: %(asm_default)}}} \ + %{!mpowerpc*: -mcom}} \ [...] r189908 | segher | 2012-07-27 04:44:37 -0700 (Fri, 27 Jul 2012) | 115 lines 2012-07-26 Segher Boessenkool <segher@kernel.crashing.org> gcc/ * common/config/rs6000/rs6000-common.c (rs6000_handle_option): Delete code for -mno-power, -mpower, and -mpower2. * config/rs6000/aix43.h (NON_POWERPC_MASKS): Delete. (SUBTARGET_OVERRIDE_OPTIONS): Delete check for POWER together with -maix64. [...]
Confirmed.
(In reply to comment #9) > Of course, if 'sldi' and 'slri' ARE supposed to be supported in "common" mode, > then this is a binutils bug. I've confirmed that these instruction are NOT in the POWER ISA, and thus gas is correct in rejecting them in "-mcom" mode. Reference: "Appendix F. New Instructions" in "Book I: PowerPC User Instruction Set Architecture" which is one volume in "PowerPC Architecture Book, Version 2.02" PDF: http://download.boulder.ibm.com/ibmdl/pub/software/dw/library/es-ppcbook1.zip Specifically, the Appendix F table lists instructions in the PowerPC ISA that are not part of the POWER ISA. The "rldicl" and "rldicr" instructions are among those listed (and as noted previously, "sldi" and "srdi" are just "extended mnemonics" for those two).
Yeah, IMHO it should have added %{!mpower*: %(asm_default)}} \ line instead of %{!mpowerpc*: -mcom}} \
(In reply to comment #14) > Yeah, IMHO it should have added > %{!mpower*: %(asm_default)}} \ > line instead of > %{!mpowerpc*: -mcom}} \ That change fixed the build failure on a POWER7 system running RHEL 6.2 that I tried it on, where it failed without the patch.
Mine.
Jakub's fix looks right.
Right, but %{!mpowerpc*: %(asm_default)}} \ instead, since the -mpower option is no more. I didn't even pick the wrong condition branch there: the original code does not do the right thing for "gcc -mno-power", which is effectively always on after my patch. But let's not always do the wrong thing; patch coming up (it needs changing in a few places more).
Author: segher Date: Thu Aug 16 00:57:37 2012 New Revision: 190427 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190427 Log: 2012-08-15 Segher Boessenkool <segher@kernel.crashing.org> gcc/ PR target/54142 * config/rs6000/driver-rs6000.c (asm_names): Use %(asm_default) instead of -mcom. * config/rs6000/rs6000.h (ASM_CPU_SPEC): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/driver-rs6000.c trunk/gcc/config/rs6000/rs6000.h
Fixed.