This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Fix C++ PRs 28736, 28737 and 28738


Lee Millward wrote:

> The fix for 27836 is a bit more involved than the other two, the ICE
> in this bug occurs inside most_general_template which is where I
> originally added the check for error_mark_node and returned NULL_TREE
> if it was found. Unfortunately this caused segmentation faults
> elsewhere because of this. I looked at the other uses of
> most_general_template but I was unable to determine how the case of
> most_general_template returning NULL_TREE is being handled.

The only case in which most_general_template should return NULL_TREE is
in cases where the most-general template cannot be determined.  I think
an example is something like:

  template <typename T> struct S {
    friend void f(T);
  };

The most-general template for S<T>::f is not known.  (There may not be
one; f might not be a template at all.)  I'm not sure why we would need
to call most_general_template in that case, but I think that's what
we're protecting against there.

> The fix I opted for to fix this bug was to leave most_general_template
> untouched and instead check for CLASSTYPE_TI_TEMPLATE being
> error_mark_node instead before we reach the original ICE point in
> most_general_template.

I'm slightly worried about the situation we've gotten ourselves into.
It seems to violate the principle that we shouldn't keep around invalid
representations.  In particular, I'm not sure we should ever allow
CLASSTYPE_TI_TEMPLATE to be the error_mark_node.  Instead, if we feel
that we need to create such a type, perhaps we should just bail out and
return error_mark_node for whatever type it is that we're creating.
What kinds of situations trigger a type with CLASSTYPE_TI_TEMPLATE set
to error_mark_node?

Separately, maybe instead of

       PR c++/28737
       PR c++/28738
       * pt.c (process_partial_specialization): Robustify.

we should instead arrange that the entry in the parameter list is not
error_mark_node, but a TREE_LIST node with an error_mark as its
TREE_VALUE?  It seems like we're running into problems because we've
introduced a typing violation; we expect these vectors to contain
TREE_LISTs, and now they sometimes contain an unvarnished error_mark_node.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]