PR/24951, checking error emitting altivec {0.0, 0.0, 0.0, 0.0}

[Paolo Bonzini]

This bug is probably latent on other versions as well, but it manifests 
on 4.1 and 4.2 as a checking ICE.

output_vec_const_move includes this code

  cst = INTVAL (CONST_VECTOR_ELT (vec, 0));
  cst2 = INTVAL (CONST_VECTOR_ELT (vec, 1));
  mode = GET_MODE (dest);

  if (TARGET_ALTIVEC)
    {
      if (zero_constant (vec, mode))
	return "vxor %0,%0,%0";

But output_vec_const_move can also be called on a V4SF constant if it is 
{0.0, 0.0, 0.0, 0.0} and in this case getting cst and cst2 will fail 
with an error like expected code 'const_int', have 'const_double'.

This is trivially fixed on 4.1 and mainline by moving cst and cst2 just 
before the usage point, as in the attached patch.

Bootstrapped powerpc-apple-darwin8.2.0, vectorization and PPC testsuites 
completed with no regressions.  I also checked with a cross compiler 
that it fixes the PR.  Andreas, could you test the patch on PPC64?  Ok 
for mainline if it passes?

Paolo
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pr24951.patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20051121/2e56f09a/attachment.ksh>