This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[3.4 PATCH] PR middle-end/17055: Backport from mainline


It's unclear whether we should close PR 17055 in bugzilla as WONTFIX
for versions prior to 4.0.0, or backport the solution to the 3.4
and possibly 3.3 branches.  My guess is that non-regression bug fixes
(such as this ICE on valid) are at the discretion of the release manager.
The following testing at least confirms that there are no technical
problems with a backport.

The following patch has been tested against the gcc-3_4-branch on
i686-pc-linux-gnu, with a full "make bootstrap", all default languages,
and regression tested with a top-level "make -k check" with no new
failures.

Ok for 3.4.3 or just close the PR?



2004-09-12  Roger Sayle  <roger@eyesopen.com>

	PR middle-end/17055
	* fold-const.c (build_zero_vector): New function to construct a
	vector (either floating point or integer) of zeros.
	(fold_convert): Internally, enable conversions of integer zero
	to arbitrary vector types, using the new build_zero_vector.

	* gcc.dg/pr17055-1.c: New test case.


Index: fold-const.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/fold-const.c,v
retrieving revision 1.322.2.14
diff -c -3 -p -r1.322.2.14 fold-const.c
*** fold-const.c	1 Sep 2004 16:40:29 -0000	1.322.2.14
--- fold-const.c	12 Sep 2004 17:05:29 -0000
*************** static tree int_const_binop (enum tree_c
*** 69,74 ****
--- 69,75 ----
  static tree const_binop (enum tree_code, tree, tree, int);
  static hashval_t size_htab_hash (const void *);
  static int size_htab_eq (const void *, const void *);
+ static tree build_zero_vector (tree);
  static tree fold_convert_const (enum tree_code, tree, tree);
  static tree fold_convert (tree, tree);
  static enum tree_code invert_tree_comparison (enum tree_code);
*************** size_diffop (tree arg0, tree arg1)
*** 1661,1666 ****
--- 1662,1684 ----
  							arg1, arg0)));
  }

+ /* Construct a vector of zero elements of vector type TYPE.  */
+
+ static tree
+ build_zero_vector (tree type)
+ {
+   tree elem, list;
+   int i, units;
+
+   elem = fold_convert_const (NOP_EXPR, TREE_TYPE (type), integer_zero_node);
+   units = TYPE_VECTOR_SUBPARTS (type);
+
+   list = NULL_TREE;
+   for (i = 0; i < units; i++)
+     list = tree_cons (NULL_TREE, elem, list);
+   return build_vector (type, list);
+ }
+

  /* Attempt to fold type conversion operation CODE of expression ARG1 to
     type TYPE.  If no simplification can be done return NULL_TREE.  */
*************** fold_convert (tree type, tree arg)
*** 1903,1908 ****
--- 1921,1928 ----
      }
    else if (TREE_CODE (type) == VECTOR_TYPE)
      {
+       if (integer_zerop (arg))
+ 	return build_zero_vector (type);
        if ((INTEGRAL_TYPE_P (orig) || POINTER_TYPE_P (orig))
  	  && GET_MODE_SIZE (TYPE_MODE (type))
  	     == GET_MODE_SIZE (TYPE_MODE (orig)))



/* PR middle-end/17055.  */
/* { dg-do compile } */
/* { dg-options "-O2 -ffast-math" } */

/* This test used to abort, beacuse we do an "integer" fold to zero, i.e.
   x - x = (T)0 where T is the type of x.  Unfortunately, fold_convert
   was unable to convert integer_zero_node to the appropriate vector type.  */

typedef float v4sf __attribute__((vector_size(16)));
typedef int v4si __attribute__((vector_size(16)));

v4sf ivf, ovf;
v4si ivi, ovi;

void testf (void)
{
  ovf = ivf - ivf;
}

void testi (void)
{
  ovi = ivi - ivi;
}


Roger
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]