This is the mail archive of the
mailing list for the GCC project.
Re: [C++ Patch] PR 84644 ("internal compiler error: in warn_misplaced_attr_for_class_type, at cp/decl.c:4718")
- From: Jason Merrill <jason at redhat dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: gcc-patches List <gcc-patches at gcc dot gnu dot org>, Nathan Sidwell <nathan at acm dot org>
- Date: Thu, 13 Dec 2018 16:03:51 -0500
- Subject: Re: [C++ Patch] PR 84644 ("internal compiler error: in warn_misplaced_attr_for_class_type, at cp/decl.c:4718")
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <CADzB+2mE2Hv6y1bPuiTn=x54CphpcNJhHuUHjYrQh0ZXpcbzRA@mail.gmail.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On 10/30/18 9:22 PM, Paolo Carlini wrote:
On 30/10/18 21:37, Jason Merrill wrote:
On 10/26/18 2:02 PM, Paolo Carlini wrote:
On 26/10/18 17:18, Jason Merrill wrote:
On Fri, Oct 26, 2018 at 4:52 AM Paolo Carlini
On 24/10/18 22:41, Jason Merrill wrote:
On 10/15/18 12:45 PM, Paolo Carlini wrote:
I would think that the MAYBE_CLASS_TYPE_P here should be
&& ((TREE_CODE (declspecs->type) != TYPENAME_TYPE
+ && TREE_CODE (declspecs->type) != DECLTYPE_TYPE
&& MAYBE_CLASS_TYPE_P (declspecs->type))
and then we can remove the TYPENAME_TYPE check. Or do we want to
allow template type parameters for some reason?
Indeed, it would be nice to just use OVERLOAD_TYPE_P. However it seems
we at least want to let through TEMPLATE_TYPE_PARMs representing
- otherwise Dodji's check a few lines below which fixed c++/51473
doesn't work anymore - and also BOUND_TEMPLATE_TEMPLATE_PARM,
we regress on template/spec32.C and template/ttp22.C because we don't
diagnose the shadowing anymore. Thus, I would say either we keep on
using MAYBE_CLASS_TYPE_P or we pick what we need, possibly we add a
Aha. I guess the answer is not to restrict that test any more, but
instead to fix the code further down so it gives a proper diagnostic
rather than call warn_misplaced_attr_for_class_type.
I see. Thus something like the below? It passes testing on x86_64-linux.
+ if ((!declared_type || TREE_CODE (declared_type) == DECLTYPE_TYPE)
+ && ! saw_friend && !error_p)
permerror (input_location, "declaration does not declare
I see no reason to make this specific to decltype. Maybe move this
diagnostic into the final 'else' block with the other declspec
diagnostics and not look at declared_type at all?
I'm not sure to fully understand: if we do that we still want to at
least minimally check that declared_type is null, like we already do,
and then we simply accept the new testcase. Is that Ok? Because, as I
probably mentioned at some point, all the other compilers I have at hand
issue a "does not declare anything" diagnostic, and we likewise do that
for the legacy __typeof. Not looking into declared_type *at all* doesn't
work with plain class types and enums, of course. Or you meant something
+ if (declspecs->attributes && warn_attributes && declared_type
+ && TREE_CODE (declared_type) != DECLTYPE_TYPE)
I think we do want to give a diagnostic about useless attributes, not
Agreed. FWIW the attached tests fine.
The problem here is that the code toward the bottom expects
"declared_type" to be the tagged type declared by a declaration with no
declarator, and in this testcase it's ending up as a DECLTYPE_TYPE.
I think once we've checked for 'auto' we don't want declared_type to be
anything that isn't OVERLOAD_TYPE_P. We can arrange that either by
checking for 'auto' first and then changing the code that sets
declared_type to use OVERLOAD_TYPE_P, or by clearing declared_type after
checking for 'auto' if it isn't OVERLOAD_TYPE_P.