[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158 Bug 84158 depends on bug 83871, which changed state. Bug 83871 Summary: wrong code for attribute const and pure on distinct template specializations https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83871 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158
--- Comment #6 from Martin Sebor ---
I tested the modified C++ 11 example below with Clang, EDG, GCC, ICC, and MSVC.
Of these, only MSVC implements the behavior I expect and doesn't warn. The
others do. (I verified that MSVC does support the attribute.)
Still, given that it's obviously meaningful to define a specialization that
does return, treating it as noreturn based on the definition of the primary is
incorrect.
Given the difference among implementations I think the standard ought to be
clarified which of the two is intended.
(See https://godbolt.org/g/sYPbD2 for Clang and MSVC output.)
template
[[noreturn]] T
g (T) { throw "not implemented"; }
template <> int
g (int) { return 0; }
int h (int i)
{
return g (i);
}
[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158
--- Comment #5 from Martin Sebor ---
(In reply to Jakub Jelinek from comment #3)
> As C++ now has standardized attributes, the question is what does the
> standard say about whether standard attributes on a template are inherited
> to specializations or not, and if the standard is fuzzy about it, what do
> other compilers do.
To my reading the standard doesn't specify attributes with enough detail to
answer the question, but inheriting attributes wouldn't make sense. For
another example, consider class templates and alignas:
template
struct alignas (32) A { T a; };
template <>
struct A { char c; };
static_assert (alignof (A) < 32, "alignof A < 32");
This passes with all compilers I tried, including Clang, GCC, ICC, and MSVC.
It would be most surprising if the rules for class templates were different
than for function templates.
[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158
--- Comment #4 from Martin Sebor ---
(In reply to Jakub Jelinek from comment #2)
> I actually think it is the right thing that the attributes from templates
> are inherited by specializations.
That cannot be correct. Because there is no way to remove an attribute from a
declaration such a design would make it impossible to declare a specialization
that differed from the primary.
Here's a modified example that should bring the problem into focus:
template T __attribute__ ((noreturn)) f (T) { __builtin_abort (); }
template <> int f (int) { return 0; } // bogus warning here
int g (int i)
{
f (i); // missing -Wreturn-type
}
t.C: In function ‘T f(T) [with T = int]’:
t.C:3:34: warning: function declared ‘noreturn’ has a ‘return’ statement
template <> int f (int) { return 0; }
^
t.C:3:34: warning: ‘noreturn’ function does return
[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158 --- Comment #3 from Jakub Jelinek --- As C++ now has standardized attributes, the question is what does the standard say about whether standard attributes on a template are inherited to specializations or not, and if the standard is fuzzy about it, what do other compilers do.
[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.5
[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I actually think it is the right thing that the attributes from templates are inherited by specializations.
[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Known to work||4.7.4 Depends on||83871 Summary|missing -Wreturn-type due |[6/7/8 Regression] missing |to incorrect handling of|-Wreturn-type due to |attributes for template |incorrect handling of |specializations |attributes for template ||specializations Known to fail||4.8.4, 4.9.4, 5.5.0, 6.4.0, ||7.2.0, 8.0 --- Comment #1 from Martin Sebor --- Bisection points to r190664 (GCC 4.8.0) as the first revision to fail to diagnose the test case: PR c++/51213 (again) * pt.c (deduction_tsubst_fntype): Remove. (fn_type_unification): Check deduction depth and call instantiate_template here. Handle default argument access checks. (determine_specialization): Suppress access control. (tsubst_decl): Check for excessive deduction depth. (recheck_decl_substitution): Make sure access control is on. (type_unification_real): Don't mess with access deferring here. (get_bindings): Adjust for fn_type_unification return type. * call.c (enum rejection_reason_code): Drop rr_template_instantiation. (template_instantiation_rejection): Remove. (struct rejection_reason): Change targs to num_targs. (template_unification_rejection, print_z_candidate): Adjust. (add_template_candidate_real): Adjust for fn_type_unification change. * class.c (resolve_address_of_overloaded_function): Likewise. * cp-tree.h: Adjust declaration. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83871 [Bug 83871] wrong code for attribute const and pure on distinct template specializations
