public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/61980] New: [GCC-4.9.1] ICE: in compute_affine_dependence, at tree-data-ref.c:4233
@ 2014-07-31 17:15 sabrinadfs at gmail dot com
  2014-07-31 17:18 ` [Bug middle-end/61980] " mpolacek at gcc dot gnu.org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: sabrinadfs at gmail dot com @ 2014-07-31 17:15 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980

            Bug ID: 61980
           Summary: [GCC-4.9.1] ICE: in compute_affine_dependence, at
                    tree-data-ref.c:4233
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sabrinadfs at gmail dot com

GCC-4.9.1
x86_64-apple-darwin11.4.2

Running the following tests:

1) 
make -s -C gcc check-gcc RUNTESTFLAGS="dg.exp=pr39794.c
--target_board=unix/-fcheck-data-deps"

GCC throw an ICE:
------------------------------------------------------------------------
/Users/sabrinasouto/Downloads/gcc4.9/gcc-4.9.1/gcc/testsuite/gcc.dg/pr39794.c:
In function 'foo':
/Users/sabrinasouto/Downloads/gcc4.9/gcc-4.9.1/gcc/testsuite/gcc.dg/pr39794.c:8:1:
internal compiler error: in compute_affine_dependence, at tree-data-ref.c:4233

/Users/sabrinasouto/Downloads/gcc4.9/gcc-4.9.1/gcc/testsuite/gcc.dg/pr39794.c:8:1:
internal compiler error: Abort trap: 6
xgcc: internal compiler error: Abort trap: 6 (program cc1)

FAIL: gcc.dg/pr39794.c (internal compiler error)
FAIL: gcc.dg/pr39794.c (test for excess errors)
Excess errors:
(Number of distance vectors differ: Banerjee has 1, Omega has 0.
Banerjee dist vectors:
  1 
Omega dist vectors:
data dependence relation:
(Data Dep: 
#(Data Ref: 
#  bb: 5 
#  stmt: _9 = *_8;
#  ref: *_8;
#  base_object: *a_5(D);
#  Access function 0: {0B, +, 4}_1
#)
#(Data Ref: 
#  bb: 5 
#  stmt: *_14 = _21;
#  ref: *_14;
#  base_object: *a_5(D);
#  Access function 0: {4B, +, 4}_1
#)
  access_fn_A: {0B, +, 4}_1
  access_fn_B: {4B, +, 4}_1
 (subscript 
  iterations_that_access_an_element_twice_in_A: [1 + 1 * x_1]
  last_conflict: 2147483646
  iterations_that_access_an_element_twice_in_B: [0 + 1 * x_1]
  last_conflict: 2147483646
  (Subscript distance: 1 ))
  inner loop index: 0
  loop nest: (1 )
)
)
------------------------------------------------------------------------


2)
make -s -C gcc check-gcc RUNTESTFLAGS="dg.exp=20090922-1.c
--target_board=unix/-fcheck-data-deps"
GCC throw an ICE:
------------------------------------------------------------------------
/Users/sabrinasouto/Downloads/gcc4.9/gcc-4.9.1/gcc/testsuite/gcc.dg/20090922-1.c:
In function 'test':
/Users/sabrinasouto/Downloads/gcc4.9/gcc-4.9.1/gcc/testsuite/gcc.dg/20090922-1.c:33:1:
internal compiler error: in compute_affine_dependence, at tree-data-ref.c:4233

/Users/sabrinasouto/Downloads/gcc4.9/gcc-4.9.1/gcc/testsuite/gcc.dg/20090922-1.c:33:1:
internal compiler error: Abort trap: 6
xgcc: internal compiler error: Abort trap: 6 (program cc1)

FAIL: gcc.dg/20090922-1.c (internal compiler error)
FAIL: gcc.dg/20090922-1.c (test for excess errors)
Excess errors:
(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: 19 
#  stmt: _47 = MEM[(struct U *)v_19 + 16B].u3;
#  ref: MEM[(struct U *)v_19 + 16B].u3;
#  base_object: MEM[(struct U *)v_19 + 16B];
#  Access function 0: 64
#)
#(Data Ref: 
#  bb: 19 
#  stmt: MEM[(struct U *)v_19 + 16B].u3 = _50;
#  ref: MEM[(struct U *)v_19 + 16B].u3;
#  base_object: MEM[(struct U *)v_19 + 16B];
#  Access function 0: 64
#)
  access_fn_A: 64
  access_fn_B: 64
 (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: (4 )
  distance_vector:   0 
  direction_vector:     =
)
)
------------------------------------------------------------------------

Can anyone confirm these bugs?


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug middle-end/61980] [GCC-4.9.1] ICE: in compute_affine_dependence, at tree-data-ref.c:4233
  2014-07-31 17:15 [Bug c/61980] New: [GCC-4.9.1] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 sabrinadfs at gmail dot com
@ 2014-07-31 17:18 ` mpolacek at gcc dot gnu.org
  2014-08-01  8:26 ` [Bug tree-optimization/61980] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 with -fcheck-data-deps rguenth at gcc dot gnu.org
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2014-07-31 17:18 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org
          Component|c                           |middle-end
           Severity|critical                    |normal


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug tree-optimization/61980] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 with -fcheck-data-deps
  2014-07-31 17:15 [Bug c/61980] New: [GCC-4.9.1] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 sabrinadfs at gmail dot com
  2014-07-31 17:18 ` [Bug middle-end/61980] " mpolacek at gcc dot gnu.org
@ 2014-08-01  8:26 ` rguenth at gcc dot gnu.org
  2014-08-01 11:03 ` sabrinadfs at gmail dot com
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-01  8:26 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-08-01
            Summary|[GCC-4.9.1] ICE: in         |ICE: in
                   |compute_affine_dependence,  |compute_affine_dependence,
                   |at tree-data-ref.c:4233     |at tree-data-ref.c:4233
                   |                            |with -fcheck-data-deps
     Ever confirmed|0                           |1
      Known to fail|                            |4.10.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note that -fcheck-data-deps never worked very reliably for me (why do you use
it?)

Confirmed on trunk.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug tree-optimization/61980] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 with -fcheck-data-deps
  2014-07-31 17:15 [Bug c/61980] New: [GCC-4.9.1] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 sabrinadfs at gmail dot com
  2014-07-31 17:18 ` [Bug middle-end/61980] " mpolacek at gcc dot gnu.org
  2014-08-01  8:26 ` [Bug tree-optimization/61980] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 with -fcheck-data-deps rguenth at gcc dot gnu.org
@ 2014-08-01 11:03 ` sabrinadfs at gmail dot com
  2014-08-01 11:05 ` rguenth at gcc dot gnu.org
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: sabrinadfs at gmail dot com @ 2014-08-01 11:03 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980

--- Comment #2 from Sabrina Souto <sabrinadfs at gmail dot com> ---
Thank you for the confirmation Richard.

Just a suggestion: if the option -fcheck-data-deps does not work well, maybe
this option should be removed from the code or at least have a comment in the
documentation related to this.




(In reply to Richard Biener from comment #1)
> Note that -fcheck-data-deps never worked very reliably for me (why do you
> use it?)
> 
> Confirmed on trunk.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug tree-optimization/61980] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 with -fcheck-data-deps
  2014-07-31 17:15 [Bug c/61980] New: [GCC-4.9.1] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 sabrinadfs at gmail dot com
                   ` (2 preceding siblings ...)
  2014-08-01 11:03 ` sabrinadfs at gmail dot com
@ 2014-08-01 11:05 ` rguenth at gcc dot gnu.org
  2014-08-01 11:21 ` sabrinadfs at gmail dot com
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-01 11:05 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's intended for debugging only:

@item -fcheck-data-deps
@opindex fcheck-data-deps
Compare the results of several data dependence analyzers.  This option
is used for debugging the data dependence analyzers.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug tree-optimization/61980] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 with -fcheck-data-deps
  2014-07-31 17:15 [Bug c/61980] New: [GCC-4.9.1] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 sabrinadfs at gmail dot com
                   ` (3 preceding siblings ...)
  2014-08-01 11:05 ` rguenth at gcc dot gnu.org
@ 2014-08-01 11:21 ` sabrinadfs at gmail dot com
  2014-08-01 11:26 ` rguenth at gcc dot gnu.org
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: sabrinadfs at gmail dot com @ 2014-08-01 11:21 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980

--- Comment #4 from Sabrina Souto <sabrinadfs at gmail dot com> ---
I don't have much experience with GCC, so I'm a bit confused with your 2
answers, please help me understanding what is happening: Based both on the
documentation and the results, I understood that the result from the dependency
analysis (Banerjee dist vectors: 0 1 , Omega dist vectors: 0) is wrong or not
expected, but this is due to the "unreliably" work of -fcheck-data-deps or,
since -fcheck-data-deps is used for debug, it is working well and this result
must be investigated?



(In reply to Richard Biener from comment #3)
> It's intended for debugging only:
> 
> @item -fcheck-data-deps
> @opindex fcheck-data-deps
> Compare the results of several data dependence analyzers.  This option
> is used for debugging the data dependence analyzers.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug tree-optimization/61980] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 with -fcheck-data-deps
  2014-07-31 17:15 [Bug c/61980] New: [GCC-4.9.1] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 sabrinadfs at gmail dot com
                   ` (4 preceding siblings ...)
  2014-08-01 11:21 ` sabrinadfs at gmail dot com
@ 2014-08-01 11:26 ` rguenth at gcc dot gnu.org
  2014-08-01 11:30 ` sabrinadfs at gmail dot com
  2015-07-18  1:18 ` spop at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-01 11:26 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Sabrina Souto from comment #4)
> I don't have much experience with GCC, so I'm a bit confused with your 2
> answers, please help me understanding what is happening: Based both on the
> documentation and the results, I understood that the result from the
> dependency analysis (Banerjee dist vectors: 0 1 , Omega dist vectors: 0) is
> wrong or not expected, but this is due to the "unreliably" work of
> -fcheck-data-deps or, since -fcheck-data-deps is used for debug, it is
> working well and this result must be investigated?

Clearly either Omega or Banerjee is wrong.  Banerjee is used by GCC for
code-generation and Omega is used to produce a comparison result only.

If Omega is wrong we don't have to worry (it only makes -fcheck-data-deps
less useful), if Banerjee is wrong then we have to worry.

I can't tell nor didn't investigate who is wrong (but from past experience
it's usually Omega).


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug tree-optimization/61980] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 with -fcheck-data-deps
  2014-07-31 17:15 [Bug c/61980] New: [GCC-4.9.1] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 sabrinadfs at gmail dot com
                   ` (5 preceding siblings ...)
  2014-08-01 11:26 ` rguenth at gcc dot gnu.org
@ 2014-08-01 11:30 ` sabrinadfs at gmail dot com
  2015-07-18  1:18 ` spop at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: sabrinadfs at gmail dot com @ 2014-08-01 11:30 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980

--- Comment #6 from Sabrina Souto <sabrinadfs at gmail dot com> ---
OK, Thank you.

(In reply to Richard Biener from comment #5)
> (In reply to Sabrina Souto from comment #4)
> > I don't have much experience with GCC, so I'm a bit confused with your 2
> > answers, please help me understanding what is happening: Based both on the
> > documentation and the results, I understood that the result from the
> > dependency analysis (Banerjee dist vectors: 0 1 , Omega dist vectors: 0) is
> > wrong or not expected, but this is due to the "unreliably" work of
> > -fcheck-data-deps or, since -fcheck-data-deps is used for debug, it is
> > working well and this result must be investigated?
> 
> Clearly either Omega or Banerjee is wrong.  Banerjee is used by GCC for
> code-generation and Omega is used to produce a comparison result only.
> 
> If Omega is wrong we don't have to worry (it only makes -fcheck-data-deps
> less useful), if Banerjee is wrong then we have to worry.
> 
> I can't tell nor didn't investigate who is wrong (but from past experience
> it's usually Omega).


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug tree-optimization/61980] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 with -fcheck-data-deps
  2014-07-31 17:15 [Bug c/61980] New: [GCC-4.9.1] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 sabrinadfs at gmail dot com
                   ` (6 preceding siblings ...)
  2014-08-01 11:30 ` sabrinadfs at gmail dot com
@ 2015-07-18  1:18 ` spop at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: spop at gcc dot gnu.org @ 2015-07-18  1:18 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980

Sebastian Pop <spop at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |spop at gcc dot gnu.org
         Resolution|---                         |FIXED
      Known to fail|4.10.0                      |

--- Comment #7 from Sebastian Pop <spop at gcc dot gnu.org> ---
Fixed in r225979.


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2015-07-18  1:18 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-31 17:15 [Bug c/61980] New: [GCC-4.9.1] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 sabrinadfs at gmail dot com
2014-07-31 17:18 ` [Bug middle-end/61980] " mpolacek at gcc dot gnu.org
2014-08-01  8:26 ` [Bug tree-optimization/61980] ICE: in compute_affine_dependence, at tree-data-ref.c:4233 with -fcheck-data-deps rguenth at gcc dot gnu.org
2014-08-01 11:03 ` sabrinadfs at gmail dot com
2014-08-01 11:05 ` rguenth at gcc dot gnu.org
2014-08-01 11:21 ` sabrinadfs at gmail dot com
2014-08-01 11:26 ` rguenth at gcc dot gnu.org
2014-08-01 11:30 ` sabrinadfs at gmail dot com
2015-07-18  1:18 ` spop at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).