On 04/13/2016 03:36 AM, Paolo Carlini wrote:
Hi,
On 12/04/2016 15:50, Jason Merrill wrote:
On 04/12/2016 09:25 AM, Paolo Carlini wrote:
in this regression we have an infinite recursion affecting the
same_type_p call at parser.c:25125 which I added in the patch for
c++/38313. The issue is that for, eg, the testcase at issue, we are
passing a TYPENAME_TYPE to same_type_p. I think we can simply handle the
problem by checking first that we have a CLASS_TYPE_P as TREE_TYPE
(type_decl). Tested x86_64-linux.
I don't see how this can be considered valid code; the typenames are
indeed mutually recursive, with no real underlying type anywhere.
clang and EDG both reject the testcase if the template is
instantiated. Please add an instantiation to the testcase. And we
should fix the recursion issue in structural_comptypes.
...but your patch is OK; even if it doesn't fix the real problem, it
isn't wrong. Only the testcase should be adjusted.
Ok. But then, if I understand correctly, our user-visible behavior
should not change much: accept the testcase (modulo the -fpermissive
detail) without an instantiation and reject it when the template is
actually instantiated. In other terms, exactly what EDG and clang also
do.
The testcase without an instantiation is ill-formed, no diagnostic
required, so we shouldn't test for accepting it, we should only test for
rejecting the variant with an instantiation.
Thus same_type_p should be fixed to simply return false in such
recursive cases without ICEing and nothing more, right? I'm not sure I
will be able to do that in time for 6.0 but I'm going to try...
resolve_typename_type should give up in such cases.
Jason
