Bug 49033 - [4.6/4.7 Regression] ICE in compute_affine_dependence (tree-data-ref.c:4090) with -O3 -fcheck-data-deps -march=amdfam10
Summary: [4.6/4.7 Regression] ICE in compute_affine_dependence (tree-data-ref.c:4090) ...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: 4.7.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-17 22:18 UTC by Arthur O'Dwyer
Modified: 2011-08-01 14:35 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-05-18 00:53:35


Attachments
Output of "ajo-gcc -w -std=c99 -O3 -march=native -fcheck-data-deps test891883150.c -v" (1.19 KB, text/plain)
2011-05-17 22:18 UTC, Arthur O'Dwyer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arthur O'Dwyer 2011-05-17 22:18:37 UTC
Created attachment 24273 [details]
Output of "ajo-gcc -w -std=c99 -O3 -march=native -fcheck-data-deps test891883150.c -v"

This reproduces for me with svn revision 173589 (2011-05-09). It doesn't
reproduce with gcc 4.5.1. I'm on Ubuntu 10.10, x86-64.

-std=c99 isn't necessary if you get rid of the declarations inside the for-loop headers. Removing -march=native causes the crash to go away.

Bug 46851 might be related.

cat >test891883150.c <<EOF
extern unsigned short g_185;
extern int g_86;
void func_72() {
    int g_120[4];
    short l_81[6] = {1,2,3,4,5,6};
    for (int p_75 = 0; p_75 < 5; ++p_75) {
        g_86 += l_81[p_75];
        for (int p_76 = 0; p_76 < 5; ++p_76)
          if (fff(l_81[0], ff(p_75) && g_86))
            complicated2(g_120);

        for (int l_217 = 0; l_217 < 6; ++l_217)
          for (g_185 = 0; g_185 < 6; ++g_185)
            l_81[g_185] = 0;
    }
}
EOF
gcc -w -std=c99 -O3 -march=native -fcheck-data-deps test891883150.c


(Number of distance vectors differ: Banerjee has 2, Omega has 1.
Banerjee dist vectors:
  0 
  1 
Omega dist vectors:
  0 
data dependence relation:
(Data Dep: 
#(Data Ref: 
#  bb: 28 
#  stmt: l_81[D.2668_112] = 0;
#  ref: l_81[D.2668_112];
#  base_object: l_81
#  Access function 0: 0
#)
#(Data Ref: 
#  bb: 29 
#  stmt: pretmp.13_30 = l_81[0];
#  ref: l_81[0];
#  base_object: l_81
#  Access function 0: 0
#)
  access_fn_A: 0
  access_fn_B: 0

 (subscript 
  iterations_that_access_an_element_twice_in_A: [0]
  last_conflict: scev_not_known;
  iterations_that_access_an_element_twice_in_B: [0]
  last_conflict: scev_not_known;
  (Subscript distance: 0
  )
 )
  inner loop index: 0
  loop nest: (1 )
  distance_vector:   0 
  direction_vector:     =
)
)
test891883150.c: In function ‘func_72’:
test891883150.c:3:6: internal compiler error: in compute_affine_dependence, at tree-data-ref.c:4090


This test case is reduced from the output of Csmith 2.1.0 (git hash 541a6480,
https://github.com/csmith-project/csmith/), using the following command line:
csmith --no-paranoid --no-longlong --no-pointers --arrays --no-jumps --consts --no-volatiles --checksum --divs --no-muls --bitfields --no-packed-struct -s 891883150
Comment 1 H.J. Lu 2011-05-18 00:53:35 UTC
-march=native is useless.  Please show outputs from

# gcc -w -std=c99 -O3 -march=native -fcheck-data-deps test891883150.c -v
# cat /proc/cpuinfo
Comment 2 Arthur O'Dwyer 2011-05-18 01:19:22 UTC
(In reply to comment #1)
> -march=native is useless.  Please show outputs from
> 
> # gcc -w -std=c99 -O3 -march=native -fcheck-data-deps test891883150.c -v
> # cat /proc/cpuinfo

I could have sworn I already attached the output from gcc -v!  But I'll try it again, once I finish rebuilding.
Comment 3 H.J. Lu 2011-05-18 02:55:03 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > -march=native is useless.  Please show outputs from
> > 
> > # gcc -w -std=c99 -O3 -march=native -fcheck-data-deps test891883150.c -v
> > # cat /proc/cpuinfo
> 
> I could have sworn I already attached the output from gcc -v!  But I'll try it
> again, once I finish rebuilding.

I got it.  It is -march=amdfam10.
Comment 4 H.J. Lu 2011-05-18 03:24:57 UTC
It is triggered by revision 161391:

http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg01309.html
Comment 5 Jakub Jelinek 2011-06-27 12:33:19 UTC
GCC 4.6.1 is being released.
Comment 6 Sebastian Pop 2011-07-08 05:14:16 UTC
I cannot reproduce this with trunk rev. 176000
gcc version 4.7.0 20110707
Might have been fixed or hidden by this patch:

2011-06-30  Richard Guenther  <rguenther@suse.de>
    
    	PR tree-optimization/46787
    	* tree-data-ref.c (dr_address_invariant_p): Remove.
    	(find_data_references_in_stmt): Invariant accesses are ok now.
    	* tree-vect-stmts.c (vectorizable_load): Handle invariant
    	loads.
    	* tree-vect-data-refs.c (vect_analyze_data_ref_access): Allow
    	invariant loads.
    
    	* gcc.dg/vect/vect-121.c: New testcase.
    
    
    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@175704
Comment 7 Arthur O'Dwyer 2011-07-08 05:37:51 UTC
(In reply to comment #6)
> I cannot reproduce this with trunk rev. 176000

I agree; I've updated to r175904, and it's not there either.
Comment 8 Richard Biener 2011-08-01 14:35:53 UTC
Fixed for trunk.  -fcheck-data-deps isn't improtant enough to warrant a backport.