On Thu, May 31, 2018 at 11:19:08AM -0400, Jason Merrill wrote:
> > In my mind the issue boils down to two questions:
> >
> > 1) should the pretty printer handle error-mark-node gracefully
> > or is it appropriate for it to abort?
> > 2) is it appropriate to be embedding/using error_mark_node in
> > valid constructs as a proxy for "unused" or "unknown" or
> > such?
> >
> > I would expect the answer to (1) to be yes. Despite that,
> > I agree with Jason that the answer to (2) should be no.
> >
> > That said, I don't think the fix for this bug needs to depend
> > on solving (2). We can avoid the ICE by changing the pretty
> > printers and adjust the openmp implementation later.
>
> The problem with embedded error_mark_node is that lots of places are
> going to blow up like this, and we don't want to change everything to
> expect it. Adjusting the pretty-printer might fix this particular
> testcase, but other things are likely to get tripped up by the same
> problem.
>
> 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.
Jakub
