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.
