* [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