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: Wed, 09 Oct 2013 10:47:22 -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> <523D86BF dot 5040106 at redhat dot com> <20131007110212 dot GJ30970 at tucnak dot zalov dot cz>
On 10/07/2013 07:02 AM, Jakub Jelinek wrote:
duplicates anywhere, but during error diagnostics. Without those two decl.c
hunks (either of them), pushdecl will sometimes return a different decl from
the original or error_mark_node, and the original fndecl passed to it has
ggc_free called on it, thus any further use of it ICEs or may ICE.
Perhaps if pushdecl returns error_mark_node,
then I'd should expect that the error has been reported already and if
it returns some other FUNCTION_DECL, then I should report it myself,
but a problem with that is that there are multiple locations that call
pushdecl (two in parser.c, one in pt.c) and more importantly, that for
the diagnostics the new fndecl is ggc_freed and thus I can't use it
for the diagnostics anymore.
True, though probably input_location is enough.
Trying to set DECL_CONTEXT to non-NULL for block_scope UDRs leads to
immediate ICEs as I said earlier, again on udr-3.C testcase:
pushdecl_maybe_friend_1 clearly doesn't expect anything to be in function scope,
and from what I remember from writing the UDR patch, it certainly wasn't the
Right. Looking at the code again I see that block-scope function
declarations have namespace DECL_CONTEXT and then have
DECL_LOCAL_FUNCTION_P set on them. That probably makes sense for UDR
functions as well.
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.
No response from omp-lang yet, so I'm not changing this yet.
Please do change it. The current behavior is just wrong, and we should
set a good example for others to follow. It's ok to fix this in a
Unfortunately it didn't work, again on the udr-3.C testcase.
mark_used was already called during instantiation of the decl, DECL_ODR_USED
got set on it, but it was actually deferred, then when mark_used is called
again on it, it is ignored. I'd need to clear DECL_ODR_USED explicitly
and call mark_used, perhaps that would work.
If deferring it is a problem you can add UDRs to the group of things
which are always instantiated immediately in mark_used:
/* Normally, we can wait until instantiation-time to synthesize DECL.
However, if DECL is a static data member initialized with a constant
or a constexpr function, we need it right now because a reference to
such a data member or a call to such function is not value-dependent.
For a function that uses auto in the return type, we need to instantiate
it to find out its type. */
if ((decl_maybe_constant_var_p (decl)
|| (TREE_CODE (decl) == FUNCTION_DECL
&& DECL_DECLARED_CONSTEXPR_P (decl))
|| undeduced_auto_decl (decl))
&& DECL_LANG_SPECIFIC (decl)
&& DECL_TEMPLATE_INFO (decl)
&& !uses_template_parms (DECL_TI_ARGS (decl)))
As for not using INIT_EXPR and just use DECL_EXPR gimplification, the problem
is that we do not actually gimplify it with the OMP_PRIV decl which has that
DECL_INITIAL from the parsing, but a different one - the original var referenced
by the clause, and that can have completely different DECL_INITIAL, or none at
+ error_at (loc, "predeclared arithmetic type in %qT"
+ error_at (loc, "reference type in %qT"