This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[3.4 PATCH] PR middle-end/17055: Backport from mainline
- From: Roger Sayle <roger at eyesopen dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Sun, 12 Sep 2004 15:58:34 -0600 (MDT)
- Subject: [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
--