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.
Please.
+ && ! (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.
Jason
