This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH] Regression in SPEC
- From: Sebastian Pop <sebastian dot pop at cri dot ensmp dot fr>
- To: Ira Rosen <IRAR at il dot ibm dot com>, gcc-patches at gcc dot gnu dot org
- Cc: pop at cri dot ensmp dot fr, Dorit Naishlos <DORIT at il dot ibm dot com>
- Date: Wed, 3 Nov 2004 13:17:09 +0100
- Subject: [PATCH] Regression in SPEC
- References: <OF90B0D2B0.849DCDF9-ONC2256F41.0026E3E0-C2256F41.002937AC@il.ibm.com>
Hello,
On Wed, Nov 03, 2004 at 09:30:12AM +0200, Ira Rosen wrote:
>
> Hi Sebastian,
>
> We got the following problem while compiling gap benchmark of SPEC2000:
>
> /Develop/mainline_ira4_build2/bin/gcc -c -o vector.o -DSYS_IS_BSD
> -DSYS_HAS_IOCTL_PROTO
> -DSYS_HAS_TIME_PROTO -DSYS_HAS_SIGNAL_PROTO -DSYS_HAS_ANSI
> -DSYS_HAS_CALLOC_PROTO
> -DSYS_HAS_STDIO_PROTO -fprofile-arcs -O3 -mcpu=G5 -mpowerpc64 -ffast-math
> -mdynamic-no-pic
> -freorder-blocks -fstrict-aliasing -ftree-vectorize -maltivec
> -fdump-tree-vect-stats
> -fdump-tree-vect-details vector.c
> virtual memory exhausted: Cannot allocate memory
> specmake: *** [vector.o] Error 1
>
> This does not happen without vectorization pass.
> I checked out a snapshot from October 13 that doesn't contain your patch (
> "Merge data dependence bits for interchanging swim loops"). It was OK. Then
> I applied your patch, and got the above error.
>
> We can reduce the testcase to the following loop (the file with the
> complete testcase is attached):
>
> unsigned long i;
> for (i = 0; i <= 5; i++)
> {
> ia[i][3] = 5;
> ia[3][i] = 5;
> }
>
> Note, that if i is int, or instead of 3 there is some variable the problem
> doesn't occur.
>
> The program gets stuck in analyze_array() function when it tries to
> allocate memory (res = xmalloc (sizeof (struct data_reference));), and
> after a while it returns with memory exhaustion error. This happens for the
> second reference: ia[3][i].
>
The problem comes from the fact that the computation of the gcd
doesn't stop, and has nothing to do with the memory allocation.
Here is a patch that solves the problem:
* tree.c (tree_fold_gcd): Use FLOOR_MOD_EXPR instead of
CEIL_MOD_EXPR.
*** tree.c.~1.442.~ Tue Nov 2 20:08:25 2004
--- tree.c Wed Nov 3 13:04:44 2004
*************** tree_fold_gcd (tree a, tree b)
*** 6029,6035 ****
while (1)
{
! a_mod_b = fold (build2 (CEIL_MOD_EXPR, type, a, b));
if (!TREE_INT_CST_LOW (a_mod_b)
&& !TREE_INT_CST_HIGH (a_mod_b))
--- 6029,6035 ----
while (1)
{
! a_mod_b = fold (build2 (FLOOR_MOD_EXPR, type, a, b));
if (!TREE_INT_CST_LOW (a_mod_b)
&& !TREE_INT_CST_HIGH (a_mod_b))