On Fri, Mar 20, 2015 at 01:30:48PM +0100, Tom de Vries wrote:
> On 20-03-15 12:57, Jakub Jelinek wrote:
> >>@@ -5569,6 +5569,7 @@ expand_omp_taskreg (struct omp_region *region)
> >>> /* Inform the callgraph about the new function. */
> >>> DECL_STRUCT_FUNCTION (child_fn)->curr_properties =
> >>> cfun->curr_properties;
> >>> cgraph_node::add_new_function (child_fn, true);
> >>>+ cgraph_node::get (child_fn)->parallelized_function = 1;
> >IMHO you want to do this in create_omp_child_function instead,
>
> That way, the patch would no longer work for parloops. The current location
> of the fix is triggered by both parloops, and the omp-in-source processing.
>
> >that way you
> >handle it not just for the parallel region, but also e.g. for the task copy
> >functions etc.
>
> I propose to handle task copy like this:
> ...
> diff --git a/gcc/omp-low.c b/gcc/omp-low.c
> index 9be39b7..f8b5f85 100644
> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -1564,6 +1564,7 @@ finalize_task_copyfn (gomp_task *task_stmt)
>
> /* Inform the callgraph about the new function. */
> cgraph_node::add_new_function (child_fn, false);
> + cgraph_node::get (child_fn)->parallelized_function = 1;
> }
>
> /* Destroy a omp_context data structures. Called through the splay tree
> ...
>
> OK if retesting succeeds?
Ok.
Jakub
