http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
--- Comment #9 from Paul H. Hargrove <PHHargrove at lbl dot gov> 2012-08-13 22:42:16 UTC --- 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.