Bug 33453 - [4.3 Regression] ICE in build2_stat, at tree.c:3110 with -ftree-parallelize-loops=4 -ftree-vectorize
Summary: [4.3 Regression] ICE in build2_stat, at tree.c:3110 with -ftree-parallelize-l...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.3.0
: P2 normal
Target Milestone: 4.3.0
Assignee: Jakub Jelinek
URL:
Keywords:
Depends on:
Blocks: 34330
  Show dependency treegraph
 
Reported: 2007-09-17 06:51 UTC by Uroš Bizjak
Modified: 2007-12-03 22:44 UTC (History)
8 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-*-*, x86_64-*-*
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2007-12-03 15:00:02


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Uroš Bizjak 2007-09-17 06:51:42 UTC
Following (delta reduced) testcase ICEs with 'gcc -O2 -msse2 -ftree-parallelize-loops=4 -ftree-vectorize' on i686 and x86_64:

gcc -O2 -msse2 -ftree-parallelize-loops=4 -ftree-vectorize 048.c
048.c: In function 'Create_BCyl':
048.c:15: internal compiler error: in build2_stat, at tree.c:3110
Please submit a full bug report,

--cut here--
typedef struct BCyl_Struct BCYL;
typedef struct BCyl_Entry_Struct BCYL_ENTRY;
struct BCyl_Entry_Struct
{
  short r1, r2;
  short h1, h2;
};
struct BCyl_Struct
{
  int number;
  BCYL_ENTRY *entry;
};
Create_BCyl (int number, double *tmp_r1, double *tmp_r2, double *tmp_h1,
             double *tmp_h2)
{
  int i, j, nr, nh;
  int *tmp_r1_index;
  int *tmp_r2_index;
  int *tmp_h1_index;
  int *tmp_h2_index;
  BCYL *bcyl;
  for (i = 0; i < bcyl->number; i++)
    {
      bcyl->entry[i].r1 = tmp_r1_index[i];
      bcyl->entry[i].r2 = tmp_r2_index[i];
      bcyl->entry[i].h1 = tmp_h1_index[i];
      bcyl->entry[i].h2 = tmp_h2_index[i];
    }
}
--cut here--
Comment 1 Andrew Pinski 2007-09-17 09:14:33 UTC
This is related to pointer plus.
Comment 2 Richard Biener 2007-09-17 11:03:23 UTC
Confirmed.  Looks like we try to build a multiplication with ptr * int:

(gdb) bt
#0  fancy_abort (
    file=0xf27848 "/space/rguenther/src/svn/pointer_plus/gcc/tree.c", 
    line=3110, function=0xf291bf "build2_stat")
    at /space/rguenther/src/svn/pointer_plus/gcc/diagnostic.c:655
#1  0x0000000000a98052 in build2_stat (code=MULT_EXPR, tt=0x2ad7bec23750, 
    arg0=0x2ad7bec6ae40, arg1=0x2ad7bec638d0)
    at /space/rguenther/src/svn/pointer_plus/gcc/tree.c:3110
#2  0x00000000006d8a51 in fold_build2_stat (code=MULT_EXPR, 
    type=0x2ad7bec23750, op0=0x2ad7bec6ae40, op1=0x2ad7bec638d0)
    at /space/rguenther/src/svn/pointer_plus/gcc/fold-const.c:13452
#3  0x00000000006a130c in fold_binary (code=MULT_EXPR, type=0x2ad7bec23750, 
    op0=0x2ad7bec638d0, op1=0x2ad7bec6ae40)
    at /space/rguenther/src/svn/pointer_plus/gcc/fold-const.c:9464
#4  0x00000000006d8a32 in fold_build2_stat (code=MULT_EXPR, 
    type=0x2ad7bec23750, op0=0x2ad7bec638d0, op1=0x2ad7bec6ae40)
    at /space/rguenther/src/svn/pointer_plus/gcc/fold-const.c:13450
#5  0x00000000008f6544 in canonicalize_loop_ivs (loop=0x2ad7be26bb40, 
    nit=0x2ad7bec5e9c0)

744                              fold_build2 (MULT_EXPR, atype,
745                                           unshare_expr (iv.step),
746                                           fold_convert (atype, var_before)))
Comment 3 Martin Michlmayr 2007-11-17 16:09:27 UTC
I get this ICE too and the backtrace looks suspiciously similar.  My testcase
needs -O3:

/* Testcase by Martin Michlmayr <tbm@cyrius.com> */

struct User
{
  char username[10];
};
void auth_set_username (struct User *user)
{
  char *d;
  char ch;
  d = user->username + (user->username[0] == '~');
  while ((ch = *d++) != '\0') /* do nothing */ ;
}
Comment 4 Martin Michlmayr 2007-11-17 16:12:25 UTC
Just that I have PLUS_EXPR rather than MULT_EXPR but it also points to
pointer plus.

pinskia, were you going to take a look at this?

#0  fancy_abort (file=0xb867e8 "gcc/tree.c", line=3110,
    function=0xb899de "build2_stat") at gcc/diagnostic.c:659
#1  0x0000000000839c5a in build2_stat (code=PLUS_EXPR, tt=0x2aaf4964c410,
    arg0=0x2aaf49668190, arg1=0x2aaf49652d80) at gcc/tree.c:3110
#2  0x0000000000592ab1 in fold_binary (code=PLUS_EXPR, type=0x2aaf4964c410,
    op0=0x2aaf49652d80, op1=0x2aaf49668190) at gcc/fold-const.c:9459
#3  0x00000000005aff29 in fold_build2_stat (code=12085224, type=0xc26,
    op0=0xb899de, op1=0x2aaf49652d80) at gcc/fold-const.c:13473
#4  0x00000000006e3e49 in split_constant_offset (exp=<value optimized out>,
    var=0x7fff61f704e0, off=0x7fff61f704d0) at gcc/tree-data-ref.c:558
#5  0x00000000006e3ce5 in split_constant_offset (exp=0x2aaf49652f00,
    var=0x7fff61f70560, off=0x7fff61f70580) at gcc/tree-data-ref.c:580
#6  0x00000000006e49c3 in dr_analyze_innermost (dr=0xff4560)
    at gcc/tree-data-ref.c:668
#7  0x00000000006e4e58 in create_data_ref (nest=0x2aaf49537960,
    memref=0x2aaf48c914c0, stmt=0x2aaf49660a50, is_read=1 '\001') at
    gcc/tree-data-ref.c:818
Comment 5 Richard Biener 2007-11-23 22:29:24 UTC
So the testcase from comment #3 is actually a regression?
Comment 6 Andrew Pinski 2007-11-23 22:34:05 UTC
The testcase in comment #1 is also a regression really because the build2_stat issues are all regressions ;).
Comment 7 Jakub Jelinek 2007-12-03 15:00:01 UTC
This isn't one bug, but many unrelated ones.
I have a fix for #c3 testcase, a fix for the p+ issue in the initial testcase
and also a different ICE with missing DECL_GIMPLE_REG_P created by parloop.
But those aren't the only ones, when that is fixed, it ICEs again in completely different spot, I'm afraid the parloop pass still has lots of issues (but those shouldn't be considered regressions, at least not P2 ones, given that it is a new pass).

Here is a cleaned up alternative to the initial testcase which doesn't use
undefined vars etc.:
/* { dg-do compile } */
/* { dg-options "-O3 -ftree-parallelize-loops=4" } */
struct T
{
  int t;
  struct { short s1, s2, s3, s4 } *s;
};
void
Create_BCyl (int *a, int *b, int *c, int *d, struct T *e)
{
  int i;
  for (i = 0; i < e->t; i++)
    {
      e->s[i].s1 = a[i];
      e->s[i].s2 = b[i];
      e->s[i].s3 = c[i];
      e->s[i].s4 = d[i];
    }
}

I guess I'll leave the rest to Zdenek/Sebastian once I have tested/posted the
fixes I have.
Comment 8 Jakub Jelinek 2007-12-03 22:35:54 UTC
Subject: Bug 33453

Author: jakub
Date: Mon Dec  3 22:35:39 2007
New Revision: 130588

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130588
Log:
	PR tree-optimization/33453
	* tree-data-ref.c (split_constant_offset): Use POINTER_PLUS_EXPR
	for pointer addition.
	* tree-parloops.c (canonicalize_loop_ivs): Likewise.
	(separate_decls_in_loop_name): Copy DECL_GIMPLE_REG_P from var to
	var_copy.

	* gcc.c-torture/compile/20071203-1.c: New test.

Added:
    trunk/gcc/testsuite/gcc.c-torture/compile/20071203-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-data-ref.c
    trunk/gcc/tree-parloops.c

Comment 9 Jakub Jelinek 2007-12-03 22:44:38 UTC
The 2 POINTER_PLUS_EXPR bugs and DECL_GIMPLE_REG_P issue fixed, the unrelated rest split into PR34330.