https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93439
--- Comment #7 from rguenther at suse dot de ---
On Tue, 28 Jan 2020, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93439
>
> --- Comment #6 from Jakub Jelinek ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93439
--- Comment #6 from Jakub Jelinek ---
(In reply to Richard Biener from comment #5)
> OK, so the reason is that when we actually create the parallel decl
> last_clique
> is not yet up to its maximum since we later loop_version another loop in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93439
--- Comment #5 from Richard Biener ---
OK, so the reason is that when we actually create the parallel decl last_clique
is not yet up to its maximum since we later loop_version another loop in the
source function. The solution is to move the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93439
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93439
--- Comment #3 from Jakub Jelinek ---
I'd say the bug is that we parallelize a loop (loop 7) which has two inner
loops (loop 10 and loop 8) and then have some code to avoid trying to
parallelize inner loops of the already parallelized loop, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93439
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |8.4
--- Comment #2 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93439
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
