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