On Tue, 18 Nov 2014, Richard Biener wrote:

> On Tue, 18 Nov 2014, Eric Botcazou wrote:
> 
> > > Now - I can see how that is easily confused by the static chain
> > > being address-taken.  But I also remember that Eric did some
> > > preparatory work to fix that, for nested functions, that is,
> > > possibly setting DECL_NONADDRESSABLE_P?  Don't remember exactly.
> > 
> > The preparatory work is DECL_NONLOCAL_FRAME.  The complete patch which does 
> > something along these lines is attached to PR tree-optimization/54779 
> > (latest 
> > version, for a 4.9-based compiler).
> 
> Ah, now I remember - this was to be able to optimize away the frame
> variable in case the nested function was inlined.
> 
> Toms case is somewhat different as I undestand as somehow LIM store
> motion doesn't handle indirect frame accesses well enough(?)  So
> he intends to load register vars in the frame into registers at the
> beginning of the nested function and restore them to the frame on
> function exit (this will probably break for recursive calls, but
> OMP offloading might be special enough that this is a non-issue there).
> 
> So marking the frame decl won't help him here (I thought we might
> mark the FIELD_DECLs corresponding to individual vars).  OTOH inside
> the nested function accesses to the static chain should be easy to
> identify.

Tom - does the following patch help?

Thanks,
Richard.

Index: gcc/omp-low.c
===================================================================
--- gcc/omp-low.c       (revision 217692)
+++ gcc/omp-low.c       (working copy)
@@ -1517,7 +1517,8 @@ fixup_child_record_type (omp_context *ct
       layout_type (type);
     }
 
-  TREE_TYPE (ctx->receiver_decl) = build_pointer_type (type);
+  TREE_TYPE (ctx->receiver_decl)
+    = build_qualified_type (build_reference_type (type), TYPE_QUAL_RESTRICT);
 }
 
 /* Instantiate decls as necessary in CTX to satisfy the data sharing

Reply via email to