Re: ICEs in print_operand() of the rs6000 backend with invalid input assembly

[Segher Boessenkool]

Hi Arseny,

On Fri, Nov 23, 2018 at 06:15:47PM +0700, Arseny Solokha wrote:
> I've found recently that rs6000 and powerpcspe backends can easily trip over
> various gcc_unreachable()'s and gcc_assert()'s in their respective copies of
> print_operand() when provided with some invalid assembly (i.e. assembly 
> written
> for other architectures).

Yup.  They should use output_operand_lossage instead.

> For example, when feeding
> gcc/testsuite/gcc.target/i386/indirect-thunk-register-4.c to the
> powerpc-targeted compiler:
> 
> % powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181118 -c
> gcc/testsuite/gcc.target/i386/indirect-thunk-register-4.c

(This is a V output modifier, which expects a trap code, which you cannot
give in inline asm at all).

> I have a hunch that this kind of invalid input should have been rejected way
> earlier, before getting to the printing out the resulting assembly, and that
> i386 backend actually does exactly that. Still, I'm not convinced that the
> current behavior is really unintended. Is it worthwhile at all to report ICEs 
> of
> this kind?

Please report them, yes!  Bonus points if you can find some way to test
this in the testsuite (preferably for all targets), testing many kinds
of input args (reg, imm, memory) and all output modifiers.

Thanks,


Segher


p.s. Patch for the %V thing:

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index ac0e210..9b29f0b 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -20971,7 +20971,7 @@ print_operand (FILE *file, rtx x, int code)
          fputs ("lge", file);  /* 5 */
          break;
        default:
-         gcc_unreachable ();
+         output_operand_lossage ("invalid %%V value");
        }
       break;