> After looking into this some more, because the PR got reopened, there were
> two issues: 1) __builtin_adjust_trampoline call needing a frame or chain (as
> can be seen on the new testcases) that wasn't added to parallel/task/target
> clauses 2) for !optimize, there is code to add those, when fram
On Mon, Jun 29, 2015 at 11:23:24AM +0200, Eric Botcazou wrote:
> > Don't you need to handle convert_nonlocal_omp_clauses similarly (need_chain
> > in that case)?
> > At least looking at your r211308 commit, for !optimize you force not just
> > the frame, but also chain.
>
> You're very likely righ
On Wed, Jul 01, 2015 at 09:52:04AM +0200, Eric Botcazou wrote:
> Jakub,
>
> > 2015-06-29 Eric Botcazou
> >
> > PR middle-end/66633
> > * tree-nested.c (convert_nonlocal_omp_clauses): Initialize need_chain
> > to true if the function is nested and if not optimizing.
> > (convert
Jakub,
> 2015-06-29 Eric Botcazou
>
> PR middle-end/66633
> * tree-nested.c (convert_nonlocal_omp_clauses): Initialize need_chain
> to true if the function is nested and if not optimizing.
> (convert_local_omp_clauses): Initialize need_frame to true if the
> funct
> Don't you need to handle convert_nonlocal_omp_clauses similarly (need_chain
> in that case)?
> At least looking at your r211308 commit, for !optimize you force not just
> the frame, but also chain.
You're very likely right, although I didn't manage to write a Fortran testcase
with my limited kn
On Fri, Jun 26, 2015 at 12:38:48PM +0200, Eric Botcazou wrote:
> this is a regression present on the mainline and 5 branch. For the attached
> Fortran testcase, the GIMPLE verifier stops the compiler on an error mark
> inserted by omp-low.c:omp_copy_decl for a FRAME variable created during the
Hi,
this is a regression present on the mainline and 5 branch. For the attached
Fortran testcase, the GIMPLE verifier stops the compiler on an error mark
inserted by omp-low.c:omp_copy_decl for a FRAME variable created during the
nested function lowering pass because it is not marked as shared
