On 05/31/2018 11:43 AM, Jakub Jelinek wrote:
On Thu, May 31, 2018 at 01:34:19PM -0400, Jason Merrill wrote:
Where is the error_mark_node coming from in the first place?

remap_type invoked during omp-low.c (scan_omp).
omp_copy_decl returns error_mark_node for decls that tree-inline.c wants
to remap, but they aren't actually remapped for some reason.
For normal VLAs gimplify.c makes sure the needed artifical decls are
firstprivatized, but in this case (VLA not in some decl's type, but just
referenced indirectly through pointers) nothing scans those unless
those temporaries are actually used in the code.

Returning error_mark_node from omp_copy_decl and then continuing seems
like the problem, then.  Would it really be that hard to return an
uninitialized variable instead?

The routine doesn't know if it is used in a context of a VLA bound or
something else, in the former case it is acceptable to swap it for some
other var, but in the latter case it would be just a bug, so using
error_mark_node in that case instead is better to catch those.
I can try to do that in tree-inline.c, but really not sure how hard would it
be.
Or handle it in the gimplifier, scan for such vars and add private clauses
for those, that will mean nothing will be passed around.

Are you still working on this approach or should I resubmit my
simple patch with the corresponding change for the C++ FE?

Martin

Reply via email to