This is the mail archive of the
mailing list for the GCC project.
Re: [gomp4] C++ OpenMP user defined reductions (take 2)
- From: Jason Merrill <jason at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Sat, 21 Sep 2013 07:45:03 -0400
- Subject: Re: [gomp4] C++ OpenMP user defined reductions (take 2)
- Authentication-results: sourceware.org; auth=none
- References: <20130827165706 dot GK21876 at tucnak dot zalov dot cz> <20130912085544 dot GS1817 at tucnak dot redhat dot com> <523C7129 dot 7030701 at redhat dot com> <20130920162509 dot GC1817 at tucnak dot redhat dot com>
On 09/20/2013 12:25 PM, Jakub Jelinek wrote:
In templates the UDRs are always FUNCTION_DECLs in classes or
at function block scope, the above one liner was I believe for the latter,
where without it duplicate_decls was returning incorrectly 0; the UDRs
from mismatching templates would actually never be seen by duplicate_decls,
but t1 was different from t2. That was before the changes to
add the mangled names to the UDR DECL_NAMEs though, I can try to remove it
and see if the whole testsuite still passes.
+ && ! (DECL_OMP_DECLARE_REDUCTION_P (newdecl)
+ && DECL_CONTEXT (newdecl) == NULL_TREE
+ && DECL_CONTEXT (olddecl) == current_function_decl))
And this looks like you need to set DECL_CONTEXT sooner on reductions.
I know it is ugly, but setting FUNCTION_DECL DECL_CONTEXT too early resulted
in all kinds of problems, when the C++ frontend doesn't support nested
functions. So the patch doesn't set DECL_CONTEXT until it is pushdecled
into the block scope.
What is calling decls_match before pushdecl?
+ if (TREE_CODE (argtype) == REFERENCE_TYPE)
+ error_at (DECL_SOURCE_LOCATION (t),
+ "function, array or reference type in "
+ "%<#pragma omp declare reduction%>");
Let's just say "reference type", since we know that's what it is.
That is true, but I wanted to match the same error message elsewhere,
otherwise the error will be different (more specific) for instantiation
vs. in non-template code.
It's more important to be specific during instantiation because we can't
always tell what the types involved actually are. So let's also add the
type in question to the diagnostic.
Though, I could of course in that second spot
just special case REFERENCE_TYPE with a separate error message
and just have one about function or array type.
That would be fine too, of course.
+ for (ix = 0; BINFO_BASE_ITERATE (binfo, ix, base_binfo); ix++)
+ id = omp_reduction_lookup (loc, orig_id, BINFO_TYPE (base_binfo));
+ if (id != NULL_TREE)
+ return id;
This should check for ambiguity rather than returning the first match.
I believe I need to discuss that on omp-lang, what exactly is the intended
behavior (and get the standard clarified). Returning the first base class
is an option (and, depth-first vs. breadth-first?), or erroring out if more
than one base class has an UDR is another.
Normal C++ lookup behavior is to check for ambiguity, so I think that's
the best bet for what the eventual defined semantics will be.
+ if (DECL_TEMPLATE_INFO (id))
+ id = instantiate_decl (id, /*defer_ok*/0, true);
Let's use mark_used instead.
Will that always instantiate it?
In contexts where that makes sense, which I would expect to be all
contexts where you can see a reduction.