https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93439
--- Comment #7 from rguenther at suse dot de <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 <jakub at gcc dot gnu.org> --- > (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 > > source function. The solution is to move the last clique setting to > > function outlining I guess. > > > > Testing patch. > > I guess that doesn't hurt, but do we really want to parallelize inner loops of > loops that we've parallelized already? > I mean, that is nested parallelism and won't always be very beneficial > (especially when in OpenMP 4.5 and earlier dynamic parallelism is disabled by > default and needs to be explicitly enabled). Sure, but that's a separate issue...
