Re: Delete redundant ppc opcode flags

[Peter Bergner <bergner at vnet dot ibm dot com>]

On Sat, 2010-07-03 at 16:22 +0930, Alan Modra wrote:
> I've been meaning to get rid of PPC_OPCODE_32 for a long time, and
> clean up logic testing this redundant flag.  PPC_OPCODE_CLASSIC isn't
> too hard to remove too.  Tested by dumping out the assembler's
> ppc_hash opcode table before and after this patch, using all the major
> cpu selection -m options.

Alan,

I was looking through a gcc testsuite run using a GCC and binutils from today,
and I noticed that gcc.target/powerpc/recip-7.c just started failing with the
following error message:

  .../xgcc -B.../ .../gcc.target/powerpc/recip-7.c -O3 -ftree-vectorize \
    -ffast-math -mrecip -mpowerpc-gfxopt -mpowerpc-gpopt -mpopcntb -lm \
    -m64 -o ./recip-7.exe
  /tmp/cc8OaJ5X.s: Assembler messages:
  /tmp/cc8OaJ5X.s:2018: Error: Unrecognized opcode: `srdi'
  /tmp/cc8OaJ5X.s:2020: Error: Unrecognized opcode: `srdi'
  ...

I tracked that down to your recent "Delete redundant ppc opcode flags"
patch, meaning a gas with that patch fails, while a gas without that
patch passes.  I believe that it is due to this hunk of that patch:

  -#define PPC64	PPC_OPCODE_64 | PPC_OPCODE_PPC
  +#define PPC64	PPC_OPCODE_64 | PPC_OPCODE_64_BRIDGE

...specifically, the loss of the PPC_OPCODE_PPC flag on the new define.
Now that change actually seems ok to me, but what it does is tickle a
latent GCC ASM_CPU_SPEC bug, namely:

    %{!mpowerpc64*: %{mpowerpc*: -mppc}} \

The problem here is that %(mpowerpc*: -mppc} matches on the -mpowerpc-gfxopt
and -mpowerpc-gpopt options above, so we end up passing -mppc to the assembler
rather than -mppc64 which we would have done if those options were not used.

Obviously, we should fix the GCC bug, but should we also add back the
PPC_OPCODE_PPC flag to PPC64 to allow old GCC sources to work with the
new gas, or are the -mpowerpc-* GCC options so uncommonly used, that 
we should only patch GCC?  Your thoughts?

Peter