https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78056
--- Comment #11 from kelvin at gcc dot gnu.org --- For example, on a system that has as support for Power9, the auto-generated $GCC_BUILD/gcc/insn-flags.h file has #define HAVE_vector_ne_v16qi_p (TARGET_P9_VECTOR) When the compiler is built on this platform, CODE_FOR_vector_ne_v16qi_p equals 2646. We "define" the builtin (call def_builtin) without checking whether we are targeting power9. But at the point that user code attempts to use this builtin, we confirm that the command-line options specify a target that has support for this instruction (i.e compiler was invoked with -mcpu=power9). If we build on a system that does not have as support for Power9, the insn-flags.h file makes no mention of HAVE_vector_ne_v16qi_p and CODE_FOR_vector_ne_v16qi_p equals CODE_FOR_nothing (0). On this platform, when we attempt to define the builtin, we get an ICE, because we do not have meaningful parameter type information for the insn that is found at index 0. The fix that I am experimenting with right now is to refrain from defining the builtin (don't call def_builtin) if the platform's as does not support Power9. So far, my initial solution passes regression except on some of the tests that I submitted with previous patches, which are expecting a particular error message, and now they are seeing a different error message. I need to think a bit more about this, after the weekend. I'm ok changing the "expected error messages" in the existing dejagnu tests. But I'm not real happy with error messages that don't tell the truth, and I'm still puzzling over what error message would be appropriate and consistent between the various platforms where the test program might run.
