Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On Tue, Feb 27, 2018 at 7:52 PM, Martin Sebor wrote: > There are many places in the C++ front-end where a string > enclosed in G_() is assigned to a pointer and later used > in a diagnostic call. Is there something different about > the usage I introduced that makes it unsuitable for > translation? The difference is that you append to the string before it is used. Looks like the _ macro might work better in this case? Jason
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On 02/28/2018 02:51 AM, Jakub Jelinek wrote: On Mon, Feb 26, 2018 at 09:19:56PM -0700, Martin Sebor wrote: PR c++/83871 PR c++/83503 * g++.dg/ext/attr-const.C: New test. * g++.dg/ext/attr-pure.C: New test. I've tried to fix these 2 tests with following patch, without -fdump-tree-optimized all the scan-tree-dump* tests are UNRESOLVED, and when you use the same function for multiple-subtests all you get is the same failures reported multiple times, but without knowing which of them failed. Unfortunately, even with this patch there are failures: FAIL: g++.dg/ext/attr-const.C -std=gnu++11 scan-tree-dump-not optimized "test_func_none_const_failed" ... so if the test is right, then something is still broken on the C++ FE side. I'll defer debugging this to you. Thanks for fixing up the unresolved tests. I have a script that checks test results against a baseline for unexpected failures but it doesn't look for differences in UNRESOLVED so I didn't see them as problems. I'll have to remember to enhance it to do that. With the unresolved problems fixed, the remaining failures are due to two problems: 1) A regression in the merging of attributes introduced by my patch. I wondered about why attributes const and pure were being handled differently than the others here: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01479.html Jason explained that parts of the structure were being copied via memcpy. Since I thought my tests were passing I took that to mean that the bits were being copied. Sigh. 2) A pre-existing bug where the C++ front end doesn't apply an attribute to a declaration of a function template previously declared without one, as in: template int f (); template int __attribute__ ((const)) f (); The root cause might be the same as the one behind bug 84294 - missing warning for ignored attribute on a function template declaration. Let me fix the first one and see what it would take to handle the second as well. Martin
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On Mon, Feb 26, 2018 at 09:19:56PM -0700, Martin Sebor wrote:
> PR c++/83871
> PR c++/83503
> * g++.dg/ext/attr-const.C: New test.
> * g++.dg/ext/attr-pure.C: New test.
I've tried to fix these 2 tests with following patch, without
-fdump-tree-optimized all the scan-tree-dump* tests are UNRESOLVED,
and when you use the same function for multiple-subtests all you get
is the same failures reported multiple times, but without knowing which
of them failed.
Unfortunately, even with this patch there are failures:
FAIL: g++.dg/ext/attr-const.C -std=gnu++11 scan-tree-dump-not optimized
"test_func_none_const_failed"
FAIL: g++.dg/ext/attr-const.C -std=gnu++11 scan-tree-dump-not optimized
"test_template_none_const_failed"
FAIL: g++.dg/ext/attr-const.C -std=gnu++14 scan-tree-dump-not optimized
"test_func_none_const_failed"
FAIL: g++.dg/ext/attr-const.C -std=gnu++14 scan-tree-dump-not optimized
"test_template_none_const_failed"
FAIL: g++.dg/ext/attr-const.C -std=gnu++17 -fconcepts scan-tree-dump-not
optimized "test_func_none_const_failed"
FAIL: g++.dg/ext/attr-const.C -std=gnu++17 -fconcepts scan-tree-dump-not
optimized "test_template_none_const_failed"
FAIL: g++.dg/ext/attr-const.C -std=gnu++17 scan-tree-dump-not optimized
"test_func_none_const_failed"
FAIL: g++.dg/ext/attr-const.C -std=gnu++17 scan-tree-dump-not optimized
"test_template_none_const_failed"
FAIL: g++.dg/ext/attr-const.C -std=gnu++2a scan-tree-dump-not optimized
"test_func_none_const_failed"
FAIL: g++.dg/ext/attr-const.C -std=gnu++2a scan-tree-dump-not optimized
"test_template_none_const_failed"
FAIL: g++.dg/ext/attr-const.C -std=gnu++98 scan-tree-dump-not optimized
"test_func_none_const_failed"
FAIL: g++.dg/ext/attr-const.C -std=gnu++98 scan-tree-dump-not optimized
"test_template_none_const_failed"
FAIL: g++.dg/ext/attr-pure.C -std=gnu++11 scan-tree-dump-not optimized
"test_template_none_pure_failed"
FAIL: g++.dg/ext/attr-pure.C -std=gnu++14 scan-tree-dump-not optimized
"test_template_none_pure_failed"
FAIL: g++.dg/ext/attr-pure.C -std=gnu++17 -fconcepts scan-tree-dump-not
optimized "test_template_none_pure_failed"
FAIL: g++.dg/ext/attr-pure.C -std=gnu++17 scan-tree-dump-not optimized
"test_template_none_pure_failed"
FAIL: g++.dg/ext/attr-pure.C -std=gnu++2a scan-tree-dump-not optimized
"test_template_none_pure_failed"
FAIL: g++.dg/ext/attr-pure.C -std=gnu++98 scan-tree-dump-not optimized
"test_template_none_pure_failed"
so if the test is right, then something is still broken on the C++ FE side.
I'll defer debugging this to you.
--- gcc/testsuite/g++.dg/ext/attr-const.C.jj2018-02-28 09:55:57.235897906
+0100
+++ gcc/testsuite/g++.dg/ext/attr-const.C 2018-02-28 10:37:09.775438593
+0100
@@ -1,37 +1,37 @@
/* PR c++/83871 - wrong code for attribute const and pure on distinct
template specializations
{ dg-do compile }
-{ dg-options "-O -Wall" } */
+{ dg-options "-O -Wall -fdump-tree-optimized" } */
int __attribute__ ((const)) fconst_none ();
int fconst_none ();
-void test_const_none_failed ();
+void test_func_const_none_failed ();
void func_const_none ()
{
int i0 = fconst_none ();
int i1 = fconst_none ();
if (i0 != i1)
-test_const_none_failed ();
+test_func_const_none_failed ();
- // { dg-final { scan-tree-dump-not "test_const_none_failed" "optimized" } }
+ // { dg-final { scan-tree-dump-not "test_func_const_none_failed" "optimized"
} }
}
int fnone_const ();
int __attribute__ ((const)) fnone_const ();
-void test_none_const_failed ();
+void test_func_none_const_failed ();
void func_none_const ()
{
int i0 = fnone_const ();
int i1 = fnone_const ();
if (i0 != i1)
-test_none_const_failed ();
+test_func_none_const_failed ();
- // { dg-final { scan-tree-dump-not "test_none_const_failed" "optimized" } }
+ // { dg-final { scan-tree-dump-not "test_func_none_const_failed" "optimized"
} }
}
@@ -41,14 +41,16 @@ int __attribute__ ((const)) fconst_none
template
int fconst_none (T);
+void test_template_const_none_failed ();
+
void template_const_none ()
{
int i0 = fconst_none (0);
int i1 = fconst_none (0);
if (i0 != i1)
-test_const_none_failed ();
+test_template_const_none_failed ();
- // { dg-final { scan-tree-dump-not "test_const_none_failed" "optimized" } }
+ // { dg-final { scan-tree-dump-not "test_template_const_none_failed"
"optimized" } }
}
@@ -58,12 +60,14 @@ int fnone_const (T);
template
int __attribute__ ((const)) fnone_const (T);
+void test_template_none_const_failed ();
+
void test_fnone_const ()
{
int i0 = fnone_const (0);
int i1 = fnone_const (0);
if (i0 != i1)
-test_none_const_failed ();
+test_template_none_const_failed ();
- // { dg-final { scan-tree-dump-not "test_none_const_failed" "optimized" } }
+ // { dg-final { scan-tree-dump-not "test_template_none_const_failed"
"optimized" } }
}
--- gcc/testsuite/g++.dg/ex
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On Mon, Feb 26, 2018 at 09:19:56PM -0700, Martin Sebor wrote: > PR c++/83871 > PR c++/83503 > * g++.dg/Wmissing-attributes.C: New test. > * g++.dg/ext/attr-const-pure.C: New test. > * g++.dg/ext/attr-const.C: New test. > * g++.dg/ext/attr-deprecated-2.C: New test. > * g++.dg/ext/attr-malloc-2.C: New test. > * g++.dg/ext/attr-malloc.C: New test. > * g++.dg/ext/attr-noinline-2.C: New test. > * g++.dg/ext/attr-noinline.C: New test. > * g++.dg/ext/attr-nonnull.C: New test. > * g++.dg/ext/attr-noreturn-2.C: New test. > * g++.dg/ext/attr-noreturn.C: New test. > * g++.dg/ext/attr-nothrow-2.C: New test. > * g++.dg/ext/attr-nothrow.C: New test. > * g++.dg/ext/attr-optimize.C: New test. > * g++.dg/ext/attr-pure.C: New test. > * g++.dg/ext/attr-returns-nonnull.C: New test. > * g++.dg/ext/attr-warning.C: New test. I'm getting: +UNRESOLVED: g++.dg/ext/attr-const.C -std=gnu++11 scan-tree-dump-not optimized "test_const_none_failed" +UNRESOLVED: g++.dg/ext/attr-const.C -std=gnu++11 scan-tree-dump-not optimized "test_const_none_failed" +UNRESOLVED: g++.dg/ext/attr-const.C -std=gnu++11 scan-tree-dump-not optimized "test_none_const_failed" +UNRESOLVED: g++.dg/ext/attr-const.C -std=gnu++11 scan-tree-dump-not optimized "test_none_const_failed" +UNRESOLVED: g++.dg/ext/attr-const.C -std=gnu++14 scan-tree-dump-not optimized "test_const_none_failed" +UNRESOLVED: g++.dg/ext/attr-const.C -std=gnu++14 scan-tree-dump-not optimized "test_const_none_failed" +UNRESOLVED: g++.dg/ext/attr-const.C -std=gnu++14 scan-tree-dump-not optimized "test_none_const_failed" +UNRESOLVED: g++.dg/ext/attr-const.C -std=gnu++14 scan-tree-dump-not optimized "test_none_const_failed" +UNRESOLVED: g++.dg/ext/attr-const.C -std=gnu++98 scan-tree-dump-not optimized "test_const_none_failed" +UNRESOLVED: g++.dg/ext/attr-const.C -std=gnu++98 scan-tree-dump-not optimized "test_const_none_failed" +UNRESOLVED: g++.dg/ext/attr-const.C -std=gnu++98 scan-tree-dump-not optimized "test_none_const_failed" +UNRESOLVED: g++.dg/ext/attr-const.C -std=gnu++98 scan-tree-dump-not optimized "test_none_const_failed" +UNRESOLVED: g++.dg/ext/attr-noinline-2.C -std=gnu++11 scan-tree-dump-not optimized" "fnoinline_always_inline *();" +UNRESOLVED: g++.dg/ext/attr-noinline-2.C -std=gnu++14 scan-tree-dump-not optimized" "fnoinline_always_inline *();" +UNRESOLVED: g++.dg/ext/attr-noinline-2.C -std=gnu++98 scan-tree-dump-not optimized" "fnoinline_always_inline *();" +UNRESOLVED: g++.dg/ext/attr-noinline.C -std=gnu++11 scan-tree-dump-not optimized" "fnoinline_always_inline *();" +UNRESOLVED: g++.dg/ext/attr-noinline.C -std=gnu++11 scan-tree-dump-not optimized" "fnone_always_inline *();" +UNRESOLVED: g++.dg/ext/attr-noinline.C -std=gnu++14 scan-tree-dump-not optimized" "fnoinline_always_inline *();" +UNRESOLVED: g++.dg/ext/attr-noinline.C -std=gnu++14 scan-tree-dump-not optimized" "fnone_always_inline *();" +UNRESOLVED: g++.dg/ext/attr-noinline.C -std=gnu++98 scan-tree-dump-not optimized" "fnoinline_always_inline *();" +UNRESOLVED: g++.dg/ext/attr-noinline.C -std=gnu++98 scan-tree-dump-not optimized" "fnone_always_inline *();" +UNRESOLVED: g++.dg/ext/attr-noreturn-2.C -std=gnu++11 scan-tree-dump-not optimized "fnone_noreturn_failed" +UNRESOLVED: g++.dg/ext/attr-noreturn-2.C -std=gnu++11 scan-tree-dump-not optimized "fnoreturn_failed" +UNRESOLVED: g++.dg/ext/attr-noreturn-2.C -std=gnu++11 scan-tree-dump-not optimized "fnoreturn_none_failed" +UNRESOLVED: g++.dg/ext/attr-noreturn-2.C -std=gnu++14 scan-tree-dump-not optimized "fnone_noreturn_failed" +UNRESOLVED: g++.dg/ext/attr-noreturn-2.C -std=gnu++14 scan-tree-dump-not optimized "fnoreturn_failed" +UNRESOLVED: g++.dg/ext/attr-noreturn-2.C -std=gnu++14 scan-tree-dump-not optimized "fnoreturn_none_failed" +UNRESOLVED: g++.dg/ext/attr-noreturn-2.C -std=gnu++98 scan-tree-dump-not optimized "fnone_noreturn_failed" +UNRESOLVED: g++.dg/ext/attr-noreturn-2.C -std=gnu++98 scan-tree-dump-not optimized "fnoreturn_failed" +UNRESOLVED: g++.dg/ext/attr-noreturn-2.C -std=gnu++98 scan-tree-dump-not optimized "fnoreturn_none_failed" +UNRESOLVED: g++.dg/ext/attr-pure.C -std=gnu++11 scan-tree-dump-not optimized "test_none_pure_failed" +UNRESOLVED: g++.dg/ext/attr-pure.C -std=gnu++11 scan-tree-dump-not optimized "test_none_pure_failed" +UNRESOLVED: g++.dg/ext/attr-pure.C -std=gnu++11 scan-tree-dump-not optimized "test_pure_none_failed" +UNRESOLVED: g++.dg/ext/attr-pure.C -std=gnu++11 scan-tree-dump-not optimized "test_pure_none_failed" +UNRESOLVED: g++.dg/ext/attr-pure.C -std=gnu++14 scan-tree-dump-not optimized "test_none_pure_failed" +UNRESOLVED: g++.dg/ext/attr-pure.C -std=gnu++14 scan-tree-dump-not optimized "test_none_pure_failed" +UNRESOLVED: g++.dg/ext/attr-pure.C -st
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On 02/27/2018 04:44 PM, Jakub Jelinek wrote:
On Mon, Feb 26, 2018 at 09:19:56PM -0700, Martin Sebor wrote:
+ /* Put together a list of the black listed attributes that the primary
+ template is declared with that the specialization is not, in case
+ it's not apparent from the most recent declaration of the primary. */
+ unsigned nattrs = 0;
+ std::string str;
+
+ for (unsigned i = 0; i != sizeof blacklist / sizeof *blacklist; ++i)
+{
+ for (unsigned j = 0; j != 2; ++j)
+ {
+ if (!lookup_attribute (blacklist[i], tmpl_attrs[j]))
+ continue;
+
+ for (unsigned k = 0; k != 1 + !!spec_attrs[1]; ++k)
+ {
+ if (lookup_attribute (blacklist[i], spec_attrs[k]))
+ break;
+
+ if (str.size ())
+ str += ", ";
+ str += "%<";
+ str += blacklist[i];
+ str += "%>";
+ ++nattrs;
+ }
+ }
+}
+
+ if (!nattrs)
+return;
+
+ if (warning_at (DECL_SOURCE_LOCATION (spec), OPT_Wmissing_attributes,
+ "explicit specialization %q#D may be missing attributes",
+ spec))
+{
+ if (nattrs > 1)
+ str = G_("missing primary template attributes ") + str;
+ else
+ str = G_("missing primary template attribute ") + str;
+
+ inform (DECL_SOURCE_LOCATION (tmpl), str.c_str ());
This is broken for multiple reasons:
1) it should be inform_n rather than inform
2) you really can't do what you're doing for translations;
G_(...) marks the string for translations, but what actually is
translated is not that string, but rather what is passed to inform,
i.e. str.c_str (), so it will be likely never translated
3) as others have mentioned, the #include you are doing is
wrong
4) I don't see justification to use std::string here
What you IMHO should use instead is use
pretty_printer str;
instead, and the pp_* APIs to add stuff in there, including
pp_begin_quote (&str, pp_show_color (global_dc->printer))
and
pp_end_quote (&str, pp_show_color (global_dc->printer))
when you want to add what %< or %> expand to,
and finally
inform_n (DECL_SOURCE_LOCATION (tmpl), nattrs,
"missing primary template attribute %s",
"missing primary template attributes %s",
pp_formatted_text (&str));
That way it should be properly translatable.
Using inform_n() would not be correct here. What's being
translated is one of exactly two forms: singular and plural.
It doesn't matter how many things the plural form refers to
because the number doesn't appear in the message. Let's ask
Google to translate the message above to a language with more
than two plural forms, such as Czech:
there are missing attributes:
https://translate.google.com/?tl=cs#auto/cs/there%20are%20missing%20attributes
vs there are 5 missing attributes:
https://translate.google.com/?tl=cs#auto/cs/there%20are%205%20missing%20attributes
Only the first form is correct when the exact number isn't
mentioned.
There are many places in the C++ front-end where a string
enclosed in G_() is assigned to a pointer and later used
in a diagnostic call. Is there something different about
the usage I introduced that makes it unsuitable for
translation?
std::string is used in a number of places in GCC. Why does
using it here need any special justification?
Using the pretty printer as you suggest also sounds
complicated to me and so prone to error but I will defer
to Jason's opinion to decide if any changes are necessary.
Martin
PS What I do think would be helpful (and what I'd like to
look into adding in stage 1) is a directive to format
attribute lists. But I'm not sure the directive will help
with cases like this one.
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On Mon, Feb 26, 2018 at 09:19:56PM -0700, Martin Sebor wrote:
> + /* Put together a list of the black listed attributes that the primary
> + template is declared with that the specialization is not, in case
> + it's not apparent from the most recent declaration of the primary. */
> + unsigned nattrs = 0;
> + std::string str;
> +
> + for (unsigned i = 0; i != sizeof blacklist / sizeof *blacklist; ++i)
> +{
> + for (unsigned j = 0; j != 2; ++j)
> + {
> + if (!lookup_attribute (blacklist[i], tmpl_attrs[j]))
> + continue;
> +
> + for (unsigned k = 0; k != 1 + !!spec_attrs[1]; ++k)
> + {
> + if (lookup_attribute (blacklist[i], spec_attrs[k]))
> + break;
> +
> + if (str.size ())
> + str += ", ";
> + str += "%<";
> + str += blacklist[i];
> + str += "%>";
> + ++nattrs;
> + }
> + }
> +}
> +
> + if (!nattrs)
> +return;
> +
> + if (warning_at (DECL_SOURCE_LOCATION (spec), OPT_Wmissing_attributes,
> + "explicit specialization %q#D may be missing attributes",
> + spec))
> +{
> + if (nattrs > 1)
> + str = G_("missing primary template attributes ") + str;
> + else
> + str = G_("missing primary template attribute ") + str;
> +
> + inform (DECL_SOURCE_LOCATION (tmpl), str.c_str ());
This is broken for multiple reasons:
1) it should be inform_n rather than inform
2) you really can't do what you're doing for translations;
G_(...) marks the string for translations, but what actually is
translated is not that string, but rather what is passed to inform,
i.e. str.c_str (), so it will be likely never translated
3) as others have mentioned, the #include you are doing is
wrong
4) I don't see justification to use std::string here
What you IMHO should use instead is use
pretty_printer str;
instead, and the pp_* APIs to add stuff in there, including
pp_begin_quote (&str, pp_show_color (global_dc->printer))
and
pp_end_quote (&str, pp_show_color (global_dc->printer))
when you want to add what %< or %> expand to,
and finally
inform_n (DECL_SOURCE_LOCATION (tmpl), nattrs,
"missing primary template attribute %s",
"missing primary template attributes %s",
pp_formatted_text (&str));
That way it should be properly translatable.
Jakub
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On 02/27/2018 04:21 PM, David Edelsohn wrote: Martin, This patch broke bootstrap. diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index 42fd872..9c2e5e6 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -24,6 +24,7 @@ along with GCC; see the file COPYING3. If not see all methods must be provided in header files; can't use a source file that contains only the method templates and "just win". */ +#include #include "config.h" #include "system.h" #include "coretypes.h" Nothing is allowed to be included before GCC config.h and system.h. And you should not be including C++ header files directly. If you truly need , the file should define INCLUDE_STRING (see system.h). Sorry, I didn't know that and my bootstrap worked. I committed r258046 (following what gcc/ipa-chkp.c does). Martin
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
Martin, This patch broke bootstrap. diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index 42fd872..9c2e5e6 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -24,6 +24,7 @@ along with GCC; see the file COPYING3. If not see all methods must be provided in header files; can't use a source file that contains only the method templates and "just win". */ +#include #include "config.h" #include "system.h" #include "coretypes.h" Nothing is allowed to be included before GCC config.h and system.h. And you should not be including C++ header files directly. If you truly need , the file should define INCLUDE_STRING (see system.h). Thanks, David
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On 02/26/2018 11:19 PM, Martin Sebor wrote:
While reviewing other related bugs I noticed 83502. This patch
doesn't fix the first test case in the bug (attribute noinline
vs always_inline). Somehow those are still copied from
the primary to the specialization and can cause conflicts.
Hmm, that's odd. Why is that?
Because duplicate_decl calls diagnose_mismatched_attributes()
on the NEWDECL and OLDDECL. (Attribute optimize would do the
same thing.) I was trying to keep the fix small but it makes
sense to take care of this as well so I have in this revision.
It does fix the second test case but with the noreturn change
it would issue a bogus -Wmissing-attributes warning for the
explicit specialization below. Adding the warn_unused_result
attribute to it would then make GCC complain about a conflict
between the added attribute and noreturn, while removing it
would lead to worse code.
template
int __attribute__ ((warn_unused_result)) f (T) { return 0; }
template <>
int __attribute__ ((noreturn)) f (int) { throw 0; }
void fi () { f (0); }
I continue to disagree with this use of attribute noreturn.
+ /* Merge the function-has-side-effects bit. */
+ if (TREE_THIS_VOLATILE (newdecl))
+ TREE_THIS_VOLATILE (olddecl) = 1;
+
+ if (merge_attr)
TREE_THIS_VOLATILE means attribute noreturn, not whether the function
has side-effects; it should be handled in the blocks controlled by
merge_attr.
Whoops. That was a silly goof. I must have misread the comment
above the macro definition. I also didn't have a test for it (or
some of the other changes I've made) so I didn't see the problem.
Attached is an enhanced version of the patch that handles (and
tests) more of the commonly used attributes. I'm not sure why
in the merge_attr block I have to merge TREE_THIS_VOLATILE and
TREE_NOTHROW back and forth but not also READONLY, PURE, or
MALLOC, but without it tests fail.
Because the memcpy from newdecl to olddecl at the end of duplicate_decls
explicitly excludes the tree_common section. I don't know why that is,
it certainly complicates the logic. That choice seems to predate the
C++ front end.
PS Would it be possible to add a new macro with "noreturn" in
the name to make it more intuitive? (And ditto perhaps also
for TREE_READONLY for "const" functions, though for whatever
reason that seems easier to decipher. I know you're all used
to it but it's far from intuitive.)
Sounds good.
PPS Duplicate_decls is over 1,400 lines long. If there is more
work to do here in stage 1 (I suspect there might be), would you
mind if I broke it up into two or more, say one for functions,
another for types, or whatever grouping makes most sense to make
it easier to follow?
Sure, there's plenty of scope for cleaning up duplicate_decls. :)
+ else
{
if (DECL_DECLARED_INLINE_P (newdecl))
DECL_DISREGARD_INLINE_LIMITS (newdecl) = true;
This looks like it will mean setting DECL_DISREGARD_INLINE_LIMITS on all
inline template specializations. I think you want to drop these two lines.
OK with that change.
Jason
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
While reviewing other related bugs I noticed 83502. This patch
doesn't fix the first test case in the bug (attribute noinline
vs always_inline). Somehow those are still copied from
the primary to the specialization and can cause conflicts.
Hmm, that's odd. Why is that?
Because duplicate_decl calls diagnose_mismatched_attributes()
on the NEWDECL and OLDDECL. (Attribute optimize would do the
same thing.) I was trying to keep the fix small but it makes
sense to take care of this as well so I have in this revision.
It does fix the second test case but with the noreturn change
it would issue a bogus -Wmissing-attributes warning for the
explicit specialization below. Adding the warn_unused_result
attribute to it would then make GCC complain about a conflict
between the added attribute and noreturn, while removing it
would lead to worse code.
template
int __attribute__ ((warn_unused_result)) f (T) { return 0; }
template <>
int __attribute__ ((noreturn)) f (int) { throw 0; }
void fi () { f (0); }
I continue to disagree with this use of attribute noreturn.
+ /* Merge the function-has-side-effects bit. */
+ if (TREE_THIS_VOLATILE (newdecl))
+TREE_THIS_VOLATILE (olddecl) = 1;
+
+ if (merge_attr)
TREE_THIS_VOLATILE means attribute noreturn, not whether the function
has side-effects; it should be handled in the blocks controlled by
merge_attr.
Whoops. That was a silly goof. I must have misread the comment
above the macro definition. I also didn't have a test for it (or
some of the other changes I've made) so I didn't see the problem.
Attached is an enhanced version of the patch that handles (and
tests) more of the commonly used attributes. I'm not sure why
in the merge_attr block I have to merge TREE_THIS_VOLATILE and
TREE_NOTHROW back and forth but not also READONLY, PURE, or
MALLOC, but without it tests fail.
Martin
PS Would it be possible to add a new macro with "noreturn" in
the name to make it more intuitive? (And ditto perhaps also
for TREE_READONLY for "const" functions, though for whatever
reason that seems easier to decipher. I know you're all used
to it but it's far from intuitive.)
PPS Duplicate_decls is over 1,400 lines long. If there is more
work to do here in stage 1 (I suspect there might be), would you
mind if I broke it up into two or more, say one for functions,
another for types, or whatever grouping makes most sense to make
it easier to follow?
PR c++/83871 - wrong code for attribute const and pure on distinct template specializations
PR c++/83503 - [8 Regression] bogus -Wattributes for const and pure on function template specialization
gcc/ChangeLog:
PR c++/83871
* gcc/doc/invoke.texi (-Wmissing-attributes): New option.
gcc/c-family/ChangeLog:
PR c++/83871
* c.opt (-Wmissing-attributes): New option.
gcc/cp/ChangeLog:
PR c++/83871
PR c++/83503
* cp-tree.h (warn_spec_missing_attributes): New function.
((check_explicit_specialization): Add an argument. Call the above
function.
* decl.c (duplicate_decls): Avoid applying primary function template's
attributes to its explicit specializations.
cp/pt.c (warn_spec_missing_attributes): Define.
gcc/testsuite/ChangeLog:
PR c++/83871
PR c++/83503
* g++.dg/Wmissing-attributes.C: New test.
* g++.dg/ext/attr-const-pure.C: New test.
* g++.dg/ext/attr-const.C: New test.
* g++.dg/ext/attr-deprecated-2.C: New test.
* g++.dg/ext/attr-malloc-2.C: New test.
* g++.dg/ext/attr-malloc.C: New test.
* g++.dg/ext/attr-noinline-2.C: New test.
* g++.dg/ext/attr-noinline.C: New test.
* g++.dg/ext/attr-nonnull.C: New test.
* g++.dg/ext/attr-noreturn-2.C: New test.
* g++.dg/ext/attr-noreturn.C: New test.
* g++.dg/ext/attr-nothrow-2.C: New test.
* g++.dg/ext/attr-nothrow.C: New test.
* g++.dg/ext/attr-optimize.C: New test.
* g++.dg/ext/attr-pure.C: New test.
* g++.dg/ext/attr-returns-nonnull.C: New test.
* g++.dg/ext/attr-warning.C: New test.
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 421b146..a4c8c8f 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -781,6 +781,11 @@ Wtemplates
C++ ObjC++ Var(warn_templates) Warning
Warn on primary template declaration.
+Wmissing-attributes
+C ObjC C++ ObjC++ Var(warn_missing_attributes) Warning LangEnabledBy(C ObjC C++ ObjC++,Wall)
+Warn about declarations of entities that may be missing attributes
+that related entities have been declared with it.
+
Wmissing-format-attribute
C ObjC C++ ObjC++ Warning Alias(Wsuggest-attribute=format)
;
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index aef022f..abcd1a6 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6463,7 +6463,8 @@ extern void end_specialization (void);
extern void begin_explicit_instantiation (void);
extern void end_explicit_instantiation (void);
extern void check_unqualified_spec_or_inst (tree, location_t);
-extern tree check_explicit_specialization (tree, tree, int, int);
+extern tree check_explicit_specialization (tree, tree, i
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On 02/21/2018 06:03 PM, Martin Sebor wrote:
On 02/13/2018 11:33 AM, Jason Merrill wrote:
On Tue, Feb 13, 2018 at 1:00 PM, Martin Sebor wrote:
On 02/13/2018 07:47 AM, Jason Merrill wrote:
On Mon, Feb 12, 2018 at 6:39 PM, Martin Sebor wrote:
I really don't think it's helpful to try to force noreturn
to match between the primary and its specializations.
I continue to disagree.
Can you explain what use case you are concerned about that isn't
already handled by the warning about noreturn function returning?
A specialization that forgot [[noreturn]] and therefore doesn't get
the desired warning.
For reference, the cases I consider important are:
1) "Unimplemented" primary template declared noreturn that throws
or exits but whose specializations return a useful value and
make use of attribute malloc (or one of the other blacklisted
attributes).
2) The converse of (1). A primary that returns a useful malloc
like value and some of whose specializations are not/cannot
be meaningfully implemented and are declared noreturn.
Right, but I still disagree with this use of noreturn, and therefore
don't consider these cases important.
Defining template specializations that differ from the primary
template in their implementation is idiomatic (analogous to
defining overloads or overridden virtual functions).
In any event, I am mainly interested in fixing the two bugs
(one a P1 regression). If you consider changing the warning
aspect of the patch a condition of accepting the fix please let
me know. Removing the noreturn keyword from the whitelist is
trivial.
Please do.
Attached is an updated patch with this change and with
the TREE_HAS_VOLATILE bit split up between types and functions.
I've also removed warn_unused_result from the blacklist (see
below).
Bootstrapped on x864_64, regression test is in progress.
Martin
While reviewing other related bugs I noticed 83502. This patch
doesn't fix the first test case in the bug (attribute noinline
vs always_inline). Somehow those are still copied from
the primary to the specialization and can cause conflicts.
Hmm, that's odd. Why is that?
It does fix the second test case but with the noreturn change
it would issue a bogus -Wmissing-attributes warning for the
explicit specialization below. Adding the warn_unused_result
attribute to it would then make GCC complain about a conflict
between the added attribute and noreturn, while removing it
would lead to worse code.
template
int __attribute__ ((warn_unused_result)) f (T) { return 0; }
template <>
int __attribute__ ((noreturn)) f (int) { throw 0; }
void fi () { f (0); }
I continue to disagree with this use of attribute noreturn.
+ /* Merge the function-has-side-effects bit. */
+ if (TREE_THIS_VOLATILE (newdecl))
+ TREE_THIS_VOLATILE (olddecl) = 1;
+
+ if (merge_attr)
TREE_THIS_VOLATILE means attribute noreturn, not whether the function
has side-effects; it should be handled in the blocks controlled by
merge_attr.
Jason
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On 02/13/2018 11:33 AM, Jason Merrill wrote:
On Tue, Feb 13, 2018 at 1:00 PM, Martin Sebor wrote:
On 02/13/2018 07:47 AM, Jason Merrill wrote:
On Mon, Feb 12, 2018 at 6:39 PM, Martin Sebor wrote:
I really don't think it's helpful to try to force noreturn
to match between the primary and its specializations.
I continue to disagree.
Can you explain what use case you are concerned about that isn't
already handled by the warning about noreturn function returning?
A specialization that forgot [[noreturn]] and therefore doesn't get
the desired warning.
For reference, the cases I consider important are:
1) "Unimplemented" primary template declared noreturn that throws
or exits but whose specializations return a useful value and
make use of attribute malloc (or one of the other blacklisted
attributes).
2) The converse of (1). A primary that returns a useful malloc
like value and some of whose specializations are not/cannot
be meaningfully implemented and are declared noreturn.
Right, but I still disagree with this use of noreturn, and therefore
don't consider these cases important.
Defining template specializations that differ from the primary
template in their implementation is idiomatic (analogous to
defining overloads or overridden virtual functions).
In any event, I am mainly interested in fixing the two bugs
(one a P1 regression). If you consider changing the warning
aspect of the patch a condition of accepting the fix please let
me know. Removing the noreturn keyword from the whitelist is
trivial.
Please do.
Attached is an updated patch with this change and with
the TREE_HAS_VOLATILE bit split up between types and functions.
I've also removed warn_unused_result from the blacklist (see
below).
Bootstrapped on x864_64, regression test is in progress.
Martin
While reviewing other related bugs I noticed 83502. This patch
doesn't fix the first test case in the bug (attribute noinline
vs always_inline). Somehow those are still copied from
the primary to the specialization and can cause conflicts.
It does fix the second test case but with the noreturn change
it would issue a bogus -Wmissing-attributes warning for the
explicit specialization below. Adding the warn_unused_result
attribute to it would then make GCC complain about a conflict
between the added attribute and noreturn, while removing it
would lead to worse code.
template
int __attribute__ ((warn_unused_result)) f (T) { return 0; }
template <>
int __attribute__ ((noreturn)) f (int) { throw 0; }
void fi () { f (0); }
PR c++/83871 - wrong code for attribute const and pure on distinct template specializations
PR c++/83503 - [8 Regression] bogus -Wattributes for const and pure on function template specialization
gcc/ChangeLog:
PR c++/83871
* gcc/doc/invoke.texi (-Wmissing-attributes): New option.
gcc/c-family/ChangeLog:
PR c++/83871
* c.opt (-Wmissing-attributes): New option.
gcc/cp/ChangeLog:
PR c++/83871
PR c++/83503
* cp-tree.h (warn_spec_missing_attributes): New function.
((check_explicit_specialization): Add an argument. Call the above
function.
* decl.c (duplicate_decls): Avoid applying primary function template's
attributes to its explicit specializations.
gcc/testsuite/ChangeLog:
PR c++/83871
PR c++/83503
* g++.dg/ext/attr-const-pure.C: New test.
* g++.dg/ext/attr-malloc.C: New test.
* g++.dg/ext/attr-nonnull.C: New test.
* g++.dg/ext/attr-nothrow.C: New test.
* g++.dg/ext/attr-nothrow-2.C: New test.
* g++.dg/ext/attr-returns-nonnull.C: New test.
* g++.dg/Wmissing-attributes.C: New test.
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 7fb386d..1d0682d 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -781,6 +781,11 @@ Wtemplates
C++ ObjC++ Var(warn_templates) Warning
Warn on primary template declaration.
+Wmissing-attributes
+C ObjC C++ ObjC++ Var(warn_missing_attributes) Warning LangEnabledBy(C ObjC C++ ObjC++,Wall)
+Warn about declarations of entities that may be missing attributes
+that related entities have been declared with it.
+
Wmissing-format-attribute
C ObjC C++ ObjC++ Warning Alias(Wsuggest-attribute=format)
;
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index a6c75ae..6255914 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6469,7 +6469,8 @@ extern void end_specialization (void);
extern void begin_explicit_instantiation (void);
extern void end_explicit_instantiation (void);
extern void check_unqualified_spec_or_inst (tree, location_t);
-extern tree check_explicit_specialization (tree, tree, int, int);
+extern tree check_explicit_specialization (tree, tree, int, int,
+ tree = NULL_TREE);
extern int num_template_headers_for_class (tree);
extern void check_template_variable (tree);
extern tree make_auto(void);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 3ccea9e..1f012ef 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -1969,10 +1969,21 @@ next_arg:;
DECL_ORIGINAL_TYPE (new
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On Tue, Feb 13, 2018 at 1:00 PM, Martin Sebor wrote: > On 02/13/2018 07:47 AM, Jason Merrill wrote: >> >> On Mon, Feb 12, 2018 at 6:39 PM, Martin Sebor wrote: >>> >>> I really don't think it's helpful to try to force noreturn >>> to match between the primary and its specializations. >> >> I continue to disagree. > > Can you explain what use case you are concerned about that isn't > already handled by the warning about noreturn function returning? A specialization that forgot [[noreturn]] and therefore doesn't get the desired warning. > For reference, the cases I consider important are: > > 1) "Unimplemented" primary template declared noreturn that throws >or exits but whose specializations return a useful value and >make use of attribute malloc (or one of the other blacklisted >attributes). > > 2) The converse of (1). A primary that returns a useful malloc >like value and some of whose specializations are not/cannot >be meaningfully implemented and are declared noreturn. Right, but I still disagree with this use of noreturn, and therefore don't consider these cases important. > Defining template specializations that differ from the primary > template in their implementation is idiomatic (analogous to > defining overloads or overridden virtual functions). > In any event, I am mainly interested in fixing the two bugs > (one a P1 regression). If you consider changing the warning > aspect of the patch a condition of accepting the fix please let > me know. Removing the noreturn keyword from the whitelist is > trivial. Please do. Jason
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On 02/13/2018 07:47 AM, Jason Merrill wrote: On Mon, Feb 12, 2018 at 6:39 PM, Martin Sebor wrote: I really don't think it's helpful to try to force noreturn to match between the primary and its specializations. I continue to disagree. Can you explain what use case you are concerned about that isn't already handled by the warning about noreturn function returning? For reference, the cases I consider important are: 1) "Unimplemented" primary template declared noreturn that throws or exits but whose specializations return a useful value and make use of attribute malloc (or one of the other blacklisted attributes). 2) The converse of (1). A primary that returns a useful malloc like value and some of whose specializations are not/cannot be meaningfully implemented and are declared noreturn. Defining template specializations that differ from the primary template in their implementation is idiomatic (analogous to defining overloads or overridden virtual functions). In any event, I am mainly interested in fixing the two bugs (one a P1 regression). If you consider changing the warning aspect of the patch a condition of accepting the fix please let me know. Removing the noreturn keyword from the whitelist is trivial. Martin
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On 02/13/2018 08:59 AM, Michael Matz wrote:
Hi,
On Mon, 12 Feb 2018, Martin Sebor wrote:
Removing noreturn from the whitelist means having to prevent
the attribute from causing conflicts with the attributes on
the blacklist. E.g., in this:
template [[malloc]] void* allocate (int);
template <> [[noreturn]] void* allocate (int);
Marking a function having a return type as noreturn doesn't make sense.
No, that's certainly not so in general(*). It makes sense
when a function cannot meaningfully be implemented to honor
its broader API contract (this applies to overloads, virtual
functions, and also template specializations). In the example
above, the author of the allocate template may wish to have it
allocate and initialize an array of T which can only be
implemented for non-void types so they define allocate like
this:
template
[[gnu::malloc]]
T*
allocate (int n)
{
return new T[n];
}
template <>
[[noreturn]]
void*
allocate (int)
{
throw "cannot allocate void arrays";
}
Defining a specialization that differs from a primary or vice
versa is a common idiom that I don't want to force users to
abandon.
As I already mentioned, this idiom has a parallel in object
oriented code (as opposed to in generic code) where a "pure"
virtual functions are declared to return a non-void type and
defined to exit/throw/abort, or not defined at all (i.e.,
the same as abort). In these case, warning would on calls
to such functions would be helpful the same that warning
on noreturn functions
So a warning in this case is actually a good thing.
A warning is only useful if it detects a bug or suggests
a potential improvement. The bug Jason is concerned about
having the warning detect involves changing the allocate
specialization in the future to return a value without
removing the noreturn atttribute. But that bug doesn't
exist with the implementation above and is already diagnosed
with the changed implementation, so there is no reason to
warn for it now.
No other use case/concern where a warning on the above might
be useful has been brought up so, AFAICS, the only instances
of the warning will be false positives.
And changing the
return type to void (so that noreturn makes sense) makes it not a
specialization anymore (or alternatively if the primary is also changed to
void then malloc doesn't make sense anymore).
Exactly. The only way to suppress the warning is to either
remove the attributes from the primary, or duplicate them
on the specialization. Neither approach would be correct
because neither would reflect the property of the declaration
it's applied to.
Martin
[*] There are a number of practical examples that show where
noreturn is useful with non-void return types. The common ones
involve overloads of APIs with an expected signature that are
not/cannot be implemented to return a value. See the cfe-dev
discussion at
http://lists.llvm.org/pipermail/cfe-dev/2011-May/014969.html
for one such example. For another one see N4226 where applying
noreturn to main was considered sufficiently useful to justify
a C++ proposal for an enhancement. (AFAIK, the proposal hasn't
yet been accepted.
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
Hi, On Mon, 12 Feb 2018, Martin Sebor wrote: > >> Removing noreturn from the whitelist means having to prevent > >> the attribute from causing conflicts with the attributes on > >> the blacklist. E.g., in this: > >> > >> template [[malloc]] void* allocate (int); > >> > >> template <> [[noreturn]] void* allocate (int); Marking a function having a return type as noreturn doesn't make sense. So a warning in this case is actually a good thing. And changing the return type to void (so that noreturn makes sense) makes it not a specialization anymore (or alternatively if the primary is also changed to void then malloc doesn't make sense anymore). Ciao, Michael.
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On Mon, Feb 12, 2018 at 6:39 PM, Martin Sebor wrote: > I really don't think it's helpful to try to force noreturn > to match between the primary and its specializations. I continue to disagree. Jason
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On 02/12/2018 10:11 AM, Jason Merrill wrote:
On Mon, Feb 12, 2018 at 11:59 AM, Martin Sebor wrote:
On 02/12/2018 09:30 AM, Jason Merrill wrote:
On Fri, Feb 9, 2018 at 6:57 PM, Martin Sebor wrote:
On 02/09/2018 12:52 PM, Jason Merrill wrote:
On 02/08/2018 04:52 PM, Martin Sebor wrote:
I took me a while to find DECL_TEMPLATE_RESULT. Hopefully
that's the right way to get the primary from a TEMPLATE_DECL.
Yes.
Attached is an updated patch. It hasn't gone through full
testing yet but please let me know if you'd like me to make
some changes.
+ const char* const whitelist[] = {
+"error", "noreturn", "warning"
+ };
Why whitelist noreturn? I would expect to want that to be consistent.
I expect noreturn to be used on a primary whose definition
is provided but that's not meant to be used the way the API
is otherwise expected to be. As in:
template
T [[noreturn]] foo () { throw "not implemented"; }
template <> int foo(); // implemented elsewhere
Marking that template as noreturn seems pointless, and possibly harmful;
the deprecated, warning, or error attributes would be better for this
situation.
I meant either:
template
T __attribute__ ((noreturn)) foo () { throw "not implemented"; }
template <> int foo(); // implemented elsewhere
or (sigh)
template
[[noreturn]] T foo () { throw "not implemented"; }
template <> int foo(); // implemented elsewhere
It lets code like this
int bar ()
{
return foo();
}
be diagnosed because it's likely a bug (as Clang does with
-Wunreachable-code). It doesn't stop code like the following
from compiling (which is good) but it instead lets them throw
at runtime which is what foo's author wants.
void bar ()
{
foo();
}
It's the same as having an "unimplemented" base virtual function
throw an exception when it's called rather than making it pure
and having calls to it abort. Declaring the base virtual function
noreturn is useful for the same reason (and also diagnosed by
Clang). I should remember to add the same warning in GCC 9.
Yes, I understood the patterns you had in mind, but I disagree with
them. My point about harmful is that declaring a function noreturn
because it's unimplemented could be a problem for when the function is
later implemented, and callers were optimized inappropriately. This
seems like a rather roundabout way to get a warning about calling an
unimplemented function, and not worth overriding the normal behavior.
Removing noreturn from the whitelist means having to prevent
the attribute from causing conflicts with the attributes on
the blacklist. E.g., in this:
template [[malloc]] void* allocate (int);
template <> [[noreturn]] void* allocate (int);
-Wmissing-attributes would warn for the missing malloc but
-Wattributes will warn once malloc is added. Ditto for all
other attributes noreturn is considered to conflict with such
as alloc_size and warn_unused_result.
This example seems rather unlikely, and the solution is to remove
[[noreturn]]. I don't think this is worth worrying about for GCC 8.
Removing [[noreturn]] is not a solution because (as I said)
-Wmissing-attributes will warn that the specialization is
missing the malloc attribute. The only solutions to avoid
both warnings are to either a) remove the malloc attribute
(and all others on the blacklist) from the primary or b) add
all of them to the specialization and remove the noreturn.
I.e., have them match. That makes sense except when either
the primary or the specialization in fact does not return.
I really don't think it's helpful to try to force noreturn
to match between the primary and its specializations.
The use case you are concerned about (a noreturn function
returning) is already diagnosed:
warning: function declared ‘noreturn’ has a ‘return’ statement
Martin
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On Mon, Feb 12, 2018 at 11:59 AM, Martin Sebor wrote:
> On 02/12/2018 09:30 AM, Jason Merrill wrote:
>>
>> On Fri, Feb 9, 2018 at 6:57 PM, Martin Sebor wrote:
>>>
>>> On 02/09/2018 12:52 PM, Jason Merrill wrote:
On 02/08/2018 04:52 PM, Martin Sebor wrote:
>
>
> I took me a while to find DECL_TEMPLATE_RESULT. Hopefully
> that's the right way to get the primary from a TEMPLATE_DECL.
Yes.
>>> Attached is an updated patch. It hasn't gone through full
>>> testing yet but please let me know if you'd like me to make
>>> some changes.
>>
>>
>>
>>> + const char* const whitelist[] = {
>>> +"error", "noreturn", "warning"
>>> + };
>>
>>
>>
>> Why whitelist noreturn? I would expect to want that to be consistent.
>
>
> I expect noreturn to be used on a primary whose definition
> is provided but that's not meant to be used the way the API
> is otherwise expected to be. As in:
>
>template
>T [[noreturn]] foo () { throw "not implemented"; }
>
>template <> int foo(); // implemented elsewhere
Marking that template as noreturn seems pointless, and possibly harmful;
the deprecated, warning, or error attributes would be better for this
situation.
>>>
>>>
>>> I meant either:
>>>
>>> template
>>> T __attribute__ ((noreturn)) foo () { throw "not implemented"; }
>>>
>>> template <> int foo(); // implemented elsewhere
>>>
>>> or (sigh)
>>>
>>> template
>>> [[noreturn]] T foo () { throw "not implemented"; }
>>>
>>> template <> int foo(); // implemented elsewhere
>>>
>>> It lets code like this
>>>
>>> int bar ()
>>> {
>>> return foo();
>>> }
>>>
>>> be diagnosed because it's likely a bug (as Clang does with
>>> -Wunreachable-code). It doesn't stop code like the following
>>> from compiling (which is good) but it instead lets them throw
>>> at runtime which is what foo's author wants.
>>>
>>> void bar ()
>>> {
>>> foo();
>>> }
>>>
>>> It's the same as having an "unimplemented" base virtual function
>>> throw an exception when it's called rather than making it pure
>>> and having calls to it abort. Declaring the base virtual function
>>> noreturn is useful for the same reason (and also diagnosed by
>>> Clang). I should remember to add the same warning in GCC 9.
>>
>>
>> Yes, I understood the patterns you had in mind, but I disagree with
>> them. My point about harmful is that declaring a function noreturn
>> because it's unimplemented could be a problem for when the function is
>> later implemented, and callers were optimized inappropriately. This
>> seems like a rather roundabout way to get a warning about calling an
>> unimplemented function, and not worth overriding the normal behavior.
>
>
> Removing noreturn from the whitelist means having to prevent
> the attribute from causing conflicts with the attributes on
> the blacklist. E.g., in this:
>
> template [[malloc]] void* allocate (int);
>
> template <> [[noreturn]] void* allocate (int);
>
> -Wmissing-attributes would warn for the missing malloc but
> -Wattributes will warn once malloc is added. Ditto for all
> other attributes noreturn is considered to conflict with such
> as alloc_size and warn_unused_result.
This example seems rather unlikely, and the solution is to remove
[[noreturn]]. I don't think this is worth worrying about for GCC 8.
> I anticipate the warning code to ultimately end up in
> the middle-end so it can handle Joseph's case as well, and
> so it can also be integrated with the attribute conflict
> machinery. It also needs to be in the middle-end to become
> usable by -Wsuggest-attribute. But I wasn't thinking of
> making any of these bigger changes until GCC 9.
> Do you want me to integrate it with the conflict stuff now?
No, leaving it for GCC 9 makes sense to me.
Jason
>>> I actually had some misgivings about both warning and deprecated
>>> for the white-listing, but not for noreturn. My (only mild)
>>> concern is that both warning and deprecated functions can and
>>> likely will in some cases still be called, and so using them to
>>> suppress the warning runs the risk that their calls might be
>>> wrong and no one will notice. Warning cannot be suppressed
>>> so it seems unlikely to be ignored, but deprecated can be.
>>> So I wonder if the white-listing for deprecated should be
>>> conditional on -Wdeprecated being enabled.
>>>
> - /* Merge the type qualifiers. */
> - if (TREE_READONLY (newdecl))
> -TREE_READONLY (olddecl) = 1;
>if (TREE_THIS_VOLATILE (newdecl))
> TREE_THIS_VOLATILE (olddecl) = 1;
> - if (TREE_NOTHROW (newdecl))
> -TREE_NOTHROW (olddecl) = 1;
> +
> + if (merge_attr)
> +{
> + /* Merge the type qualifiers. */
> + if (TREE_READONLY (newdecl))
> +TREE_READONLY (olddecl) = 1;
> +
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On 02/12/2018 09:30 AM, Jason Merrill wrote:
On Fri, Feb 9, 2018 at 6:57 PM, Martin Sebor wrote:
On 02/09/2018 12:52 PM, Jason Merrill wrote:
On 02/08/2018 04:52 PM, Martin Sebor wrote:
I took me a while to find DECL_TEMPLATE_RESULT. Hopefully
that's the right way to get the primary from a TEMPLATE_DECL.
Yes.
Attached is an updated patch. It hasn't gone through full
testing yet but please let me know if you'd like me to make
some changes.
+ const char* const whitelist[] = {
+"error", "noreturn", "warning"
+ };
Why whitelist noreturn? I would expect to want that to be consistent.
I expect noreturn to be used on a primary whose definition
is provided but that's not meant to be used the way the API
is otherwise expected to be. As in:
template
T [[noreturn]] foo () { throw "not implemented"; }
template <> int foo(); // implemented elsewhere
Marking that template as noreturn seems pointless, and possibly harmful;
the deprecated, warning, or error attributes would be better for this
situation.
I meant either:
template
T __attribute__ ((noreturn)) foo () { throw "not implemented"; }
template <> int foo(); // implemented elsewhere
or (sigh)
template
[[noreturn]] T foo () { throw "not implemented"; }
template <> int foo(); // implemented elsewhere
It lets code like this
int bar ()
{
return foo();
}
be diagnosed because it's likely a bug (as Clang does with
-Wunreachable-code). It doesn't stop code like the following
from compiling (which is good) but it instead lets them throw
at runtime which is what foo's author wants.
void bar ()
{
foo();
}
It's the same as having an "unimplemented" base virtual function
throw an exception when it's called rather than making it pure
and having calls to it abort. Declaring the base virtual function
noreturn is useful for the same reason (and also diagnosed by
Clang). I should remember to add the same warning in GCC 9.
Yes, I understood the patterns you had in mind, but I disagree with
them. My point about harmful is that declaring a function noreturn
because it's unimplemented could be a problem for when the function is
later implemented, and callers were optimized inappropriately. This
seems like a rather roundabout way to get a warning about calling an
unimplemented function, and not worth overriding the normal behavior.
Removing noreturn from the whitelist means having to prevent
the attribute from causing conflicts with the attributes on
the blacklist. E.g., in this:
template [[malloc]] void* allocate (int);
template <> [[noreturn]] void* allocate (int);
-Wmissing-attributes would warn for the missing malloc but
-Wattributes will warn once malloc is added. Ditto for all
other attributes noreturn is considered to conflict with such
as alloc_size and warn_unused_result.
I anticipate the warning code to ultimately end up in
the middle-end so it can handle Joseph's case as well, and
so it can also be integrated with the attribute conflict
machinery. It also needs to be in the middle-end to become
usable by -Wsuggest-attribute. But I wasn't thinking of
making any of these bigger changes until GCC 9.
Do you want me to integrate it with the conflict stuff now?
Martin
I actually had some misgivings about both warning and deprecated
for the white-listing, but not for noreturn. My (only mild)
concern is that both warning and deprecated functions can and
likely will in some cases still be called, and so using them to
suppress the warning runs the risk that their calls might be
wrong and no one will notice. Warning cannot be suppressed
so it seems unlikely to be ignored, but deprecated can be.
So I wonder if the white-listing for deprecated should be
conditional on -Wdeprecated being enabled.
- /* Merge the type qualifiers. */
- if (TREE_READONLY (newdecl))
-TREE_READONLY (olddecl) = 1;
if (TREE_THIS_VOLATILE (newdecl))
TREE_THIS_VOLATILE (olddecl) = 1;
- if (TREE_NOTHROW (newdecl))
-TREE_NOTHROW (olddecl) = 1;
+
+ if (merge_attr)
+{
+ /* Merge the type qualifiers. */
+ if (TREE_READONLY (newdecl))
+TREE_READONLY (olddecl) = 1;
+}
+ else
+{
+ /* Set the bits that correspond to the const function
attributes. */
+ TREE_READONLY (olddecl) = TREE_READONLY (newdecl);
+}
Let's limit the const/volatile handling here to non-functions, and
handle the const/noreturn attributes for functions in the later hunk
along with nothrow/malloc/pure.
I had to keep the TREE_HAS_VOLATILE handling as is since it
applies to functions too (has side-effects). Otherwise the
attr-nothrow-2.C test fails.
When I mentioned "noreturn" above I was referring to
TREE_HAS_VOLATILE; sorry I wasn't clear. For functions it should be
handled along with nothrow/readonly/malloc/pure.
Jason
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On Fri, Feb 9, 2018 at 6:57 PM, Martin Sebor wrote:
> On 02/09/2018 12:52 PM, Jason Merrill wrote:
>> On 02/08/2018 04:52 PM, Martin Sebor wrote:
>>>
>>> I took me a while to find DECL_TEMPLATE_RESULT. Hopefully
>>> that's the right way to get the primary from a TEMPLATE_DECL.
>>
>> Yes.
>>
> Attached is an updated patch. It hasn't gone through full
> testing yet but please let me know if you'd like me to make
> some changes.
> + const char* const whitelist[] = {
> +"error", "noreturn", "warning"
> + };
Why whitelist noreturn? I would expect to want that to be consistent.
>>>
>>> I expect noreturn to be used on a primary whose definition
>>> is provided but that's not meant to be used the way the API
>>> is otherwise expected to be. As in:
>>>
>>>template
>>>T [[noreturn]] foo () { throw "not implemented"; }
>>>
>>>template <> int foo(); // implemented elsewhere
>>
>> Marking that template as noreturn seems pointless, and possibly harmful;
>> the deprecated, warning, or error attributes would be better for this
>> situation.
>
> I meant either:
>
> template
> T __attribute__ ((noreturn)) foo () { throw "not implemented"; }
>
> template <> int foo(); // implemented elsewhere
>
> or (sigh)
>
> template
> [[noreturn]] T foo () { throw "not implemented"; }
>
> template <> int foo(); // implemented elsewhere
>
> It lets code like this
>
> int bar ()
> {
> return foo();
> }
>
> be diagnosed because it's likely a bug (as Clang does with
> -Wunreachable-code). It doesn't stop code like the following
> from compiling (which is good) but it instead lets them throw
> at runtime which is what foo's author wants.
>
> void bar ()
> {
> foo();
> }
>
> It's the same as having an "unimplemented" base virtual function
> throw an exception when it's called rather than making it pure
> and having calls to it abort. Declaring the base virtual function
> noreturn is useful for the same reason (and also diagnosed by
> Clang). I should remember to add the same warning in GCC 9.
Yes, I understood the patterns you had in mind, but I disagree with
them. My point about harmful is that declaring a function noreturn
because it's unimplemented could be a problem for when the function is
later implemented, and callers were optimized inappropriately. This
seems like a rather roundabout way to get a warning about calling an
unimplemented function, and not worth overriding the normal behavior.
> I actually had some misgivings about both warning and deprecated
> for the white-listing, but not for noreturn. My (only mild)
> concern is that both warning and deprecated functions can and
> likely will in some cases still be called, and so using them to
> suppress the warning runs the risk that their calls might be
> wrong and no one will notice. Warning cannot be suppressed
> so it seems unlikely to be ignored, but deprecated can be.
> So I wonder if the white-listing for deprecated should be
> conditional on -Wdeprecated being enabled.
>
>>> - /* Merge the type qualifiers. */
>>> - if (TREE_READONLY (newdecl))
>>> -TREE_READONLY (olddecl) = 1;
>>>if (TREE_THIS_VOLATILE (newdecl))
>>> TREE_THIS_VOLATILE (olddecl) = 1;
>>> - if (TREE_NOTHROW (newdecl))
>>> -TREE_NOTHROW (olddecl) = 1;
>>> +
>>> + if (merge_attr)
>>> +{
>>> + /* Merge the type qualifiers. */
>>> + if (TREE_READONLY (newdecl))
>>> +TREE_READONLY (olddecl) = 1;
>>> +}
>>> + else
>>> +{
>>> + /* Set the bits that correspond to the const function
>>> attributes. */
>>> + TREE_READONLY (olddecl) = TREE_READONLY (newdecl);
>>> +}
>>
>>
>> Let's limit the const/volatile handling here to non-functions, and
>> handle the const/noreturn attributes for functions in the later hunk
>> along with nothrow/malloc/pure.
>
>
> I had to keep the TREE_HAS_VOLATILE handling as is since it
> applies to functions too (has side-effects). Otherwise the
> attr-nothrow-2.C test fails.
When I mentioned "noreturn" above I was referring to
TREE_HAS_VOLATILE; sorry I wasn't clear. For functions it should be
handled along with nothrow/readonly/malloc/pure.
Jason
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On 02/09/2018 12:52 PM, Jason Merrill wrote:
On 02/08/2018 04:52 PM, Martin Sebor wrote:
I took me a while to find DECL_TEMPLATE_RESULT. Hopefully
that's the right way to get the primary from a TEMPLATE_DECL.
Yes.
Attached is an updated patch. It hasn't gone through full
testing yet but please let me know if you'd like me to make
some changes.
+ const char* const whitelist[] = {
+"error", "noreturn", "warning"
+ };
Why whitelist noreturn? I would expect to want that to be consistent.
I expect noreturn to be used on a primary whose definition
is provided but that's not meant to be used the way the API
is otherwise expected to be. As in:
template
T [[noreturn]] foo () { throw "not implemented"; }
template <> int foo(); // implemented elsewhere
Marking that template as noreturn seems pointless, and possibly harmful;
the deprecated, warning, or error attributes would be better for this
situation.
I meant either:
template
T __attribute__ ((noreturn)) foo () { throw "not implemented"; }
template <> int foo(); // implemented elsewhere
or (sigh)
template
[[noreturn]] T foo () { throw "not implemented"; }
template <> int foo(); // implemented elsewhere
It lets code like this
int bar ()
{
return foo();
}
be diagnosed because it's likely a bug (as Clang does with
-Wunreachable-code). It doesn't stop code like the following
from compiling (which is good) but it instead lets them throw
at runtime which is what foo's author wants.
void bar ()
{
foo();
}
It's the same as having an "unimplemented" base virtual function
throw an exception when it's called rather than making it pure
and having calls to it abort. Declaring the base virtual function
noreturn is useful for the same reason (and also diagnosed by
Clang). I should remember to add the same warning in GCC 9.
I actually had some misgivings about both warning and deprecated
for the white-listing, but not for noreturn. My (only mild)
concern is that both warning and deprecated functions can and
likely will in some cases still be called, and so using them to
suppress the warning runs the risk that their calls might be
wrong and no one will notice. Warning cannot be suppressed
so it seems unlikely to be ignored, but deprecated can be.
So I wonder if the white-listing for deprecated should be
conditional on -Wdeprecated being enabled.
- /* Merge the type qualifiers. */
- if (TREE_READONLY (newdecl))
-TREE_READONLY (olddecl) = 1;
if (TREE_THIS_VOLATILE (newdecl))
TREE_THIS_VOLATILE (olddecl) = 1;
- if (TREE_NOTHROW (newdecl))
-TREE_NOTHROW (olddecl) = 1;
+
+ if (merge_attr)
+{
+ /* Merge the type qualifiers. */
+ if (TREE_READONLY (newdecl))
+TREE_READONLY (olddecl) = 1;
+}
+ else
+{
+ /* Set the bits that correspond to the const function
attributes. */
+ TREE_READONLY (olddecl) = TREE_READONLY (newdecl);
+}
Let's limit the const/volatile handling here to non-functions, and
handle the const/noreturn attributes for functions in the later hunk
along with nothrow/malloc/pure.
I had to keep the TREE_HAS_VOLATILE handling as is since it
applies to functions too (has side-effects). Otherwise the
attr-nothrow-2.C test fails.
I try to avoid reformatting code that I'm not actually changing, to
avoid noise in e.g. git blame.
Okay.
Attached is an updated patch. Besides the changes above
I also used a plural "attributes" in the name of the option
for consistency with other attribute options, expanded
the documentation, and enhanced one of the tests.
Bootstrapped on x86_64-linux (tests still running).
Martin
PR c++/83871 - wrong code for attribute const and pure on distinct template specializations
PR c++/83503 - [8 Regression] bogus -Wattributes for const and pure on function template specialization
gcc/ChangeLog:
PR c++/83871
* gcc/doc/invoke.texi (-Wmissing-attribute): New option.
gcc/c-family/ChangeLog:
PR c++/83871
* c.opt (-Wmissing-attribute): New option.
gcc/cp/ChangeLog:
PR c++/83871
PR c++/83503
* cp-tree.h (warn_spec_missing_attributes): New function.
((check_explicit_specialization): Add an argument. Call the above
function.
* decl.c (duplicate_decls): Avoid applying primary function template's
attributes to its explicit specializations.
gcc/testsuite/ChangeLog:
PR c++/83871
PR c++/83503
* g++.dg/ext/attr-const-pure.C: New test.
* g++.dg/ext/attr-malloc.C: New test.
* g++.dg/ext/attr-nonnull.C: New test.
* g++.dg/ext/attr-nothrow.C: New test.
* g++.dg/ext/attr-nothrow-2.C: New test.
* g++.dg/ext/attr-returns-nonnull.C: New test.
* g++.dg/Wmissing-attribute.C: New test.
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 9c71726..1039274 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -781,6 +781,11 @@ Wtemplates
C++ ObjC++ Var(warn_templates) Warning
Warn on primary template declaration.
+Wmissing-attributes
+C ObjC C+
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On 02/08/2018 04:52 PM, Martin Sebor wrote:
I took me a while to find DECL_TEMPLATE_RESULT. Hopefully
that's the right way to get the primary from a TEMPLATE_DECL.
Yes.
Attached is an updated patch. It hasn't gone through full
testing yet but please let me know if you'd like me to make
some changes.
+ const char* const whitelist[] = {
+ "error", "noreturn", "warning"
+ };
Why whitelist noreturn? I would expect to want that to be consistent.
I expect noreturn to be used on a primary whose definition
is provided but that's not meant to be used the way the API
is otherwise expected to be. As in:
template
T [[noreturn]] foo () { throw "not implemented"; }
template <> int foo(); // implemented elsewhere
Marking that template as noreturn seems pointless, and possibly harmful;
the deprecated, warning, or error attributes would be better for this
situation.
- /* Merge the type qualifiers. */
- if (TREE_READONLY (newdecl))
- TREE_READONLY (olddecl) = 1;
if (TREE_THIS_VOLATILE (newdecl))
TREE_THIS_VOLATILE (olddecl) = 1;
- if (TREE_NOTHROW (newdecl))
- TREE_NOTHROW (olddecl) = 1;
+
+ if (merge_attr)
+ {
+ /* Merge the type qualifiers. */
+ if (TREE_READONLY (newdecl))
+ TREE_READONLY (olddecl) = 1;
+ }
+ else
+ {
+ /* Set the bits that correspond to the const function attributes. */
+ TREE_READONLY (olddecl) = TREE_READONLY (newdecl);
+ }
Let's limit the const/volatile handling here to non-functions, and
handle the const/noreturn attributes for functions in the later hunk
along with nothrow/malloc/pure.
- /* Merge parameter attributes. */
+ /* Merge or assign parameter attributes. */
tree oldarg, newarg;
- for (oldarg = DECL_ARGUMENTS(olddecl),
- newarg = DECL_ARGUMENTS(newdecl);
- oldarg && newarg;
- oldarg = DECL_CHAIN(oldarg), newarg = DECL_CHAIN(newarg)) {
- DECL_ATTRIBUTES (newarg)
- = (*targetm.merge_decl_attributes) (oldarg, newarg);
- DECL_ATTRIBUTES (oldarg) = DECL_ATTRIBUTES (newarg);
- }
-
+ for (oldarg = DECL_ARGUMENTS (olddecl),
+newarg = DECL_ARGUMENTS (newdecl);
+ oldarg && newarg;
+ oldarg = DECL_CHAIN (oldarg), newarg = DECL_CHAIN (newarg))
+ {
+ DECL_ATTRIBUTES (newarg)
+ = (*targetm.merge_decl_attributes) (oldarg, newarg);
+ DECL_ATTRIBUTES (oldarg) = DECL_ATTRIBUTES (newarg);
+ }
+
I try to avoid reformatting code that I'm not actually changing, to
avoid noise in e.g. git blame.
Jason
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
__attribute__ ((nothrow))? The patch includes a test case with
wrong-code due to inheriting the attribute. With exception
specifications having to match between the primary and its
specializations it's the only way to make them different.
I've left this unchanged but let me know if I'm missing
something.
Yeah, I think you're right. But I notice that the existing code (and
thus your patch) touches TREE_NOTHROW in two places, and the first one
seems wrong; we only want it inside the FUNCTION_DECL section.
I think I see what you mean. I don't follow all the details
of all the code here but hopefully I got it right.
Rather than pass them down into register_specialization and
duplicate_decls, check_explicit_specialization could compare the
attribute list to the attributes on the template itself.
I took me a while to find DECL_TEMPLATE_RESULT. Hopefully
that's the right way to get the primary from a TEMPLATE_DECL.
+ if (!merge_attr)
+{
+ /* Remove the two function attributes that are, in fact,
+ treated as (quasi) type attributes. */
+ tree attrs = TYPE_ATTRIBUTES (newtype);
+ tree newattrs = remove_attribute ("nonnull", attrs);
+ newattrs = remove_attribute ("returns_nonnull", attrs);
+ if (newattrs != attrs)
+TYPE_ATTRIBUTES (newtype) = newattrs;
+}
Instead of this, we should avoid calling merge_types and just use
TREE_TYPE (newdecl) for newtype.
Ah, great, thanks. That works and fixes the outstanding FAILs
in the tests.
/* Merge the data types specified in the two decls. */
-newtype = merge_types (TREE_TYPE (newdecl), TREE_TYPE (olddecl));
+newtype = TREE_TYPE (newdecl);
I meant to avoid merging only when !merge_attr; we should still merge if
merge_attr is true.
Doh! Of course. Silly mistake. Sorry.
Attached is an updated patch. It hasn't gone through full
testing yet but please let me know if you'd like me to make
some changes.
+ const char* const whitelist[] = {
+"error", "noreturn", "warning"
+ };
Why whitelist noreturn? I would expect to want that to be consistent.
I expect noreturn to be used on a primary whose definition
is provided but that's not meant to be used the way the API
is otherwise expected to be. As in:
template
T [[noreturn]] foo () { throw "not implemented"; }
template <> int foo(); // implemented elsewhere
Beyond that, noreturn can only be paired with a small number
of the attributes on the black list (just format and nonnull),
otherwise it or the other one is ignored (and -Wattributes
is issued). I suppose noreturn would make sense together
with format on a template that formatted a message before
throwing or printing it and exiting. But format is almost
never used in templates so it seems like a stretch. If
you think it's important or if you have a use case in mind
that I'm not thinking of let me know.
Attached is the updated patch, this time bootstrapped and
regtested on x86_64-linux.
Martin
PR c++/83871 - wrong code for attribute const and pure on distinct template specializations
PR c++/83503 - [8 Regression] bogus -Wattributes for const and pure on function template specialization
gcc/ChangeLog:
PR c++/83871
* gcc/doc/invoke.texi (-Wmissing-attribute): New option.
gcc/c-family/ChangeLog:
PR c++/83871
* c.opt (-Wmissing-attribute): New option.
gcc/cp/ChangeLog:
PR c++/83871
PR c++/83503
* cp-tree.h (warn_spec_missing_attributes): New function.
((check_explicit_specialization): Add an argument. Call the above
function.
* decl.c (duplicate_decls): Avoid applying primary function template's
attributes to its explicit specializations.
gcc/testsuite/ChangeLog:
PR c++/83871
PR c++/83503
* g++.dg/ext/attr-const-pure.C: New test.
* g++.dg/ext/attr-malloc.C: New test.
* g++.dg/ext/attr-nonnull.C: New test.
* g++.dg/ext/attr-nothrow.C: New test.
* g++.dg/ext/attr-nothrow-2.C: New test.
* g++.dg/ext/attr-returns-nonnull.C: New test.
* g++.dg/Wmissing-attribute.C: New test.
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 9c71726..a4d5e61 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -781,6 +781,11 @@ Wtemplates
C++ ObjC++ Var(warn_templates) Warning
Warn on primary template declaration.
+Wmissing-attribute
+C ObjC C++ ObjC++ Var(warn_missing_attribute) Warning LangEnabledBy(C ObjC C++ ObjC++,Wall)
+Warn about declarations of entities that may be missing attributes
+that related entities have been declared with it.
+
Wmissing-format-attribute
C ObjC C++ ObjC++ Warning Alias(Wsuggest-attribute=format)
;
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index a53f4fd..87b7916 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6470,7 +6470,8 @@ extern void end_specialization (void);
extern void begin_explicit_instantiation (void);
extern void end_explicit_instantiation (void);
extern void check_unqualified_spec_or_inst (tree, location_t);
-extern tree check_explicit_specialization (tree, tree, i
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On 02/06/2018 11:01 PM, Martin Sebor wrote:
On 02/05/2018 02:52 PM, Jason Merrill wrote:
On 02/04/2018 07:07 PM, Martin Sebor wrote:
To resolve the underlying root cause of the P1 bug c++/83503
- bogus -Wattributes for const and pure on function template
specialization, that we discussed last week, I've taken a stab
at making the change to avoid applying primary template's
attributes to its explicit specializations. (The bug tracking
the underlying root cause is 83871 - wrong code for attribute
const and pure on distinct template specializations).
The attached patch is what I have so far. It's incomplete
and not all the tests pass for a couple of reasons:
1) it only handles function templates (not class templates),
and I have no tests for those yet,
Class templates may already work the way you expect; at least aligned
does, though that doesn't involve TYPE_ATTRIBUTES.
Hmm, it seems that we currently don't propagate unused even to implicit
instantiations, a bug in the other direction:
template struct [[gnu::unused]] A { };
int main()
{
A a; // shouldn't warn
}
I opened bug 84221 to track it. It's a regression WRT 4.7.
For types, it's not completely clear to me what should be
expected for attribute deprecated. Not inheriting the
attribute means that users would be able to explicitly
specialize a deprecated primary template which is in most
cases contrary to the intent of the attribute.
On the other hand, inheriting it means that there would be
no good way to deprecate the primary without also deprecating
its explicit specializations (because declaring the explicit
specializations would trigger the warning). The use case
for this was mentioned by Richard in the core discussion
(deprecating the std::numeric_limits primary).
I can't think of any way to make it work. The only solution
that comes to mind is to use the name of the source file (or
header) in which the primary is defined and allow explicit
specializations to be defined in it while issuing the warning
for those defined in other files. But this definitely seems
like GCC 9 material.
Yes, we definitely don't need to mess with this now.
2) it isn't effective for the nonnull and returns_nonnull
attributes because they are treated as type attributes,
3) the change to deal with attributes on function arguments
may be unnecessary (I couldn't come up with any that would
be propagated from the primary -- are there some?).
Yes, I think this is unnecessary.
Okay, thanks for confirming that.
Before I proceed with it I first want to make sure that it should
be fixed for GCC 8,
Some of it, I think. Probably not the whole issue.
that duplicate_decls is the right place for these changes
I think so.
and that (2) should be fixed by treating those
and other such attributes by applying them to function decls.
This seems out of bounds for GCC 8. It would also mean that we couldn't
use such attributes on pointers to functions.
+ TREE_NOTHROW (newdecl) |= TREE_NOTHROW (olddecl);
TREE_NOTHROW is mostly a non-attribute property, so I'd leave it out of
this.
__attribute__ ((nothrow))? The patch includes a test case with
wrong-code due to inheriting the attribute. With exception
specifications having to match between the primary and its
specializations it's the only way to make them different.
I've left this unchanged but let me know if I'm missing
something.
Yeah, I think you're right. But I notice that the existing code (and
thus your patch) touches TREE_NOTHROW in two places, and the first one
seems wrong; we only want it inside the FUNCTION_DECL section.
+ DECL_IS_MALLOC (olddecl) = DECL_IS_MALLOC (newdecl);
If a template is declared to be malloc, IMO we should really warn if a
specialization is missing that attribute, it seems certain to be a
mistake.
I tend to agree that it's likely a mistake. Though warning
in the front-end will lead to false positives if the function
isn't malloc. Ideally, this would be detected in the middle-
end (where -Wsuggest-attribute=malloc is handled) but I suspect
it's too late for that. I've added a simple warning for it.
In general, I think we should (optionally) warn if a template has
attributes and a specialization doesn't, as a user might have been
relying on the current behavior.
I've added a new option, -Wmissing-attribute. In bug 81824
Joseph asked for such a warning for C (for function resolvers
and aliases) and so I'll use the same option for both (I expect
it's too late to handle 81824 in GCC 8 but I'll finish it in
GCC 9). Adding the warning required passing some additional
attributes around and so more churn.
Rather than pass them down into register_specialization and
duplicate_decls, check_explicit_specialization could compare the
attribute list to the attributes on the template itself.
+ if (!merge_attr)
+ {
+ /* Remove the two function attributes that are, in fact,
+ treated as (quasi) type
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On 02/05/2018 02:52 PM, Jason Merrill wrote:
On 02/04/2018 07:07 PM, Martin Sebor wrote:
To resolve the underlying root cause of the P1 bug c++/83503
- bogus -Wattributes for const and pure on function template
specialization, that we discussed last week, I've taken a stab
at making the change to avoid applying primary template's
attributes to its explicit specializations. (The bug tracking
the underlying root cause is 83871 - wrong code for attribute
const and pure on distinct template specializations).
The attached patch is what I have so far. It's incomplete
and not all the tests pass for a couple of reasons:
1) it only handles function templates (not class templates),
and I have no tests for those yet,
Class templates may already work the way you expect; at least aligned
does, though that doesn't involve TYPE_ATTRIBUTES.
Hmm, it seems that we currently don't propagate unused even to implicit
instantiations, a bug in the other direction:
template struct [[gnu::unused]] A { };
int main()
{
A a; // shouldn't warn
}
I opened bug 84221 to track it. It's a regression WRT 4.7.
For types, it's not completely clear to me what should be
expected for attribute deprecated. Not inheriting the
attribute means that users would be able to explicitly
specialize a deprecated primary template which is in most
cases contrary to the intent of the attribute.
On the other hand, inheriting it means that there would be
no good way to deprecate the primary without also deprecating
its explicit specializations (because declaring the explicit
specializations would trigger the warning). The use case
for this was mentioned by Richard in the core discussion
(deprecating the std::numeric_limits primary).
I can't think of any way to make it work. The only solution
that comes to mind is to use the name of the source file (or
header) in which the primary is defined and allow explicit
specializations to be defined in it while issuing the warning
for those defined in other files. But this definitely seems
like GCC 9 material.
2) it isn't effective for the nonnull and returns_nonnull
attributes because they are treated as type attributes,
3) the change to deal with attributes on function arguments
may be unnecessary (I couldn't come up with any that would
be propagated from the primary -- are there some?).
Yes, I think this is unnecessary.
Okay, thanks for confirming that.
Before I proceed with it I first want to make sure that it should
be fixed for GCC 8,
Some of it, I think. Probably not the whole issue.
that duplicate_decls is the right place for these changes
I think so.
and that (2) should be fixed by treating those
and other such attributes by applying them to function decls.
This seems out of bounds for GCC 8. It would also mean that we couldn't
use such attributes on pointers to functions.
+ TREE_NOTHROW (newdecl) |= TREE_NOTHROW (olddecl);
TREE_NOTHROW is mostly a non-attribute property, so I'd leave it out of
this.
__attribute__ ((nothrow))? The patch includes a test case with
wrong-code due to inheriting the attribute. With exception
specifications having to match between the primary and its
specializations it's the only way to make them different.
I've left this unchanged but let me know if I'm missing
something.
+ DECL_IS_MALLOC (olddecl) = DECL_IS_MALLOC (newdecl);
If a template is declared to be malloc, IMO we should really warn if a
specialization is missing that attribute, it seems certain to be a mistake.
I tend to agree that it's likely a mistake. Though warning
in the front-end will lead to false positives if the function
isn't malloc. Ideally, this would be detected in the middle-
end (where -Wsuggest-attribute=malloc is handled) but I suspect
it's too late for that. I've added a simple warning for it.
In general, I think we should (optionally) warn if a template has
attributes and a specialization doesn't, as a user might have been
relying on the current behavior.
I've added a new option, -Wmissing-attribute. In bug 81824
Joseph asked for such a warning for C (for function resolvers
and aliases) and so I'll use the same option for both (I expect
it's too late to handle 81824 in GCC 8 but I'll finish it in
GCC 9). Adding the warning required passing some additional
attributes around and so more churn.
+ if (!merge_attr)
+{
+ /* Remove the two function attributes that are, in fact,
+ treated as (quasi) type attributes. */
+ tree attrs = TYPE_ATTRIBUTES (newtype);
+ tree newattrs = remove_attribute ("nonnull", attrs);
+ newattrs = remove_attribute ("returns_nonnull", attrs);
+ if (newattrs != attrs)
+TYPE_ATTRIBUTES (newtype) = newattrs;
+}
Instead of this, we should avoid calling merge_types and just use
TREE_TYPE (newdecl) for newtype.
Ah, great, thanks. That works and fixes the outstanding FAILs
in the tests.
Attached is an updated patch. It hasn't
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On 02/05/2018 05:55 PM, Joseph Myers wrote: On Mon, 5 Feb 2018, Martin Sebor wrote: On 02/05/2018 04:44 PM, Joseph Myers wrote: On Sun, 4 Feb 2018, Martin Sebor wrote: We've talked about (2) in the past (bug 71463) but this seems like an opportunity to revisit it and (hopefully) make a change to treat these the same as all other function attributes rather than type attributes. Besides fixing the wrong code bugs and I'd say that actually more attributes should be made into type attributes where they are currently function attributes - anything that affects optimizations or warnings in the caller based on properties of the callee is something where it's meaningful to have a pointer-to-function where the pointed-to function type has that property. What then happens when the pointer to which the attributes are transferred (presumably by initialization) is then assigned the address of a function that has different attributes that? The pointer object gets the attributes by being declared with the appropriate attribute. (Example: the error member of struct cpp_callbacks in cpplib.h.) If a pointer to a function that lacks the required property is stored in the object with pointer-to-attributed-function type, that's a bug - just as it's a bug if a function is declared with an attribute without satisfying the required properties. Oh, I see what you mean. I thought you were suggesting to transparently transfer the attributes to the pointer type on initialization. I agree that making it possible to explictly specify some of these attributes on function pointers (i.e., making them type attributes) would be useful. Provided, of course, that incompatible conversions were diagnosed. Martin
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On Mon, 5 Feb 2018, Martin Sebor wrote: > On 02/05/2018 04:44 PM, Joseph Myers wrote: > > On Sun, 4 Feb 2018, Martin Sebor wrote: > > > > > We've talked about (2) in the past (bug 71463) but this seems > > > like an opportunity to revisit it and (hopefully) make a change > > > to treat these the same as all other function attributes rather > > > than type attributes. Besides fixing the wrong code bugs and > > > > I'd say that actually more attributes should be made into type attributes > > where they are currently function attributes - anything that affects > > optimizations or warnings in the caller based on properties of the callee > > is something where it's meaningful to have a pointer-to-function where the > > pointed-to function type has that property. > > What then happens when the pointer to which the attributes are > transferred (presumably by initialization) is then assigned > the address of a function that has different attributes that? The pointer object gets the attributes by being declared with the appropriate attribute. (Example: the error member of struct cpp_callbacks in cpplib.h.) If a pointer to a function that lacks the required property is stored in the object with pointer-to-attributed-function type, that's a bug - just as it's a bug if a function is declared with an attribute without satisfying the required properties. -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On 02/05/2018 04:44 PM, Joseph Myers wrote: On Sun, 4 Feb 2018, Martin Sebor wrote: We've talked about (2) in the past (bug 71463) but this seems like an opportunity to revisit it and (hopefully) make a change to treat these the same as all other function attributes rather than type attributes. Besides fixing the wrong code bugs and I'd say that actually more attributes should be made into type attributes where they are currently function attributes - anything that affects optimizations or warnings in the caller based on properties of the callee is something where it's meaningful to have a pointer-to-function where the pointed-to function type has that property. What then happens when the pointer to which the attributes are transferred (presumably by initialization) is then assigned the address of a function that has different attributes that? Based on testing, transferring type attributes doesn't seem to have a beneficial effect on the generated code. For example, G++ treats const and pure as function attributes but returns_nonnull as a type attribute. Calls made from function templates via a pointer are treated according to the constness and "pureness" of the actual argument to the template (i.e., that of the function passed to it as an argument). But similar calls seem to disregard the returns_nonnull attribute and lead to suboptimal code when a function with the attribute is passed to the template. I haven't spent enough time to understand why that is yet, but anecdotally what I have seen suggests using type attributes leads to problems. At least in C++. Martin
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On Sun, 4 Feb 2018, Martin Sebor wrote: > We've talked about (2) in the past (bug 71463) but this seems > like an opportunity to revisit it and (hopefully) make a change > to treat these the same as all other function attributes rather > than type attributes. Besides fixing the wrong code bugs and I'd say that actually more attributes should be made into type attributes where they are currently function attributes - anything that affects optimizations or warnings in the caller based on properties of the callee is something where it's meaningful to have a pointer-to-function where the pointed-to function type has that property. -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
On 02/04/2018 07:07 PM, Martin Sebor wrote:
To resolve the underlying root cause of the P1 bug c++/83503
- bogus -Wattributes for const and pure on function template
specialization, that we discussed last week, I've taken a stab
at making the change to avoid applying primary template's
attributes to its explicit specializations. (The bug tracking
the underlying root cause is 83871 - wrong code for attribute
const and pure on distinct template specializations).
The attached patch is what I have so far. It's incomplete
and not all the tests pass for a couple of reasons:
1) it only handles function templates (not class templates),
and I have no tests for those yet,
Class templates may already work the way you expect; at least aligned
does, though that doesn't involve TYPE_ATTRIBUTES.
Hmm, it seems that we currently don't propagate unused even to implicit
instantiations, a bug in the other direction:
template struct [[gnu::unused]] A { };
int main()
{
A a; // shouldn't warn
}
2) it isn't effective for the nonnull and returns_nonnull
attributes because they are treated as type attributes,
3) the change to deal with attributes on function arguments
may be unnecessary (I couldn't come up with any that would
be propagated from the primary -- are there some?).
Yes, I think this is unnecessary.
Before I proceed with it I first want to make sure that it should
be fixed for GCC 8,
Some of it, I think. Probably not the whole issue.
that duplicate_decls is the right place for these changes
I think so.
and that (2) should be fixed by treating those
and other such attributes by applying them to function decls.
This seems out of bounds for GCC 8. It would also mean that we couldn't
use such attributes on pointers to functions.
+ TREE_NOTHROW (newdecl) |= TREE_NOTHROW (olddecl);
TREE_NOTHROW is mostly a non-attribute property, so I'd leave it out of
this.
+ DECL_IS_MALLOC (olddecl) = DECL_IS_MALLOC (newdecl);
If a template is declared to be malloc, IMO we should really warn if a
specialization is missing that attribute, it seems certain to be a mistake.
In general, I think we should (optionally) warn if a template has
attributes and a specialization doesn't, as a user might have been
relying on the current behavior.
+ if (!merge_attr)
+ {
+ /* Remove the two function attributes that are, in fact,
+treated as (quasi) type attributes. */
+ tree attrs = TYPE_ATTRIBUTES (newtype);
+ tree newattrs = remove_attribute ("nonnull", attrs);
+ newattrs = remove_attribute ("returns_nonnull", attrs);
+ if (newattrs != attrs)
+ TYPE_ATTRIBUTES (newtype) = newattrs;
+ }
Instead of this, we should avoid calling merge_types and just use
TREE_TYPE (newdecl) for newtype.
Jason
[RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)
To resolve the underlying root cause of the P1 bug c++/83503
- bogus -Wattributes for const and pure on function template
specialization, that we discussed last week, I've taken a stab
at making the change to avoid applying primary template's
attributes to its explicit specializations. (The bug tracking
the underlying root cause is 83871 - wrong code for attribute
const and pure on distinct template specializations).
The attached patch is what I have so far. It's incomplete
and not all the tests pass for a couple of reasons:
1) it only handles function templates (not class templates),
and I have no tests for those yet,
2) it isn't effective for the nonnull and returns_nonnull
attributes because they are treated as type attributes,
3) the change to deal with attributes on function arguments
may be unnecessary (I couldn't come up with any that would
be propagated from the primary -- are there some?).
Before I proceed with it I first want to make sure that it should
be fixed for GCC 8, that duplicate_decls is the right place for
these changes, and that (2) should be fixed by treating those
and other such attributes by applying them to function decls.
We've talked about (2) in the past (bug 71463) but this seems
like an opportunity to revisit it and (hopefully) make a change
to treat these the same as all other function attributes rather
than type attributes. Besides fixing the wrong code bugs and
false positives it will also make them more intuitive to use.
There have been a number of bug reports from users confused by
the -Wignored-attributes warnings caused by this unusual handling.
Thanks
Martin
PR c++/83871 - wrong code for attribute const and pure on distinct template specializations
PR c++/83503 - [8 Regression] bogus -Wattributes for const and pure on function template specialization
gcc/cp/ChangeLog:
PR c++/83871
PR c++/83503
* decl.c (duplicate_decls): Avoid applying primary function
template's attributes to its explicit specializations.
gcc/testsuite/ChangeLog:
PR c++/83871
PR c++/83503
* g++.dg/ext/attr-const-pure.C: New test.
* g++.dg/ext/attr-malloc.C: New test.
* g++.dg/ext/attr-nonnull.C: New test.
* g++.dg/ext/attr-nothrow.C: New test.
* g++.dg/ext/attr-returns-nonnull.C: New test.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 244a3ef..21c3051 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -1971,10 +1971,21 @@ next_arg:;
DECL_ORIGINAL_TYPE (newdecl) = DECL_ORIGINAL_TYPE (olddecl);
}
- /* Copy all the DECL_... slots specified in the new decl
- except for any that we copy here from the old type. */
- DECL_ATTRIBUTES (newdecl)
-= (*targetm.merge_decl_attributes) (olddecl, newdecl);
+ /* True to merge attributes between the declarations, false to
+ set OLDDECL's attributes to those of NEWDECL (for template
+ explicit specializations that specify their own attributes
+ independent of those specified for the primary template). */
+ const bool merge_attr = (TREE_CODE (newdecl) != FUNCTION_DECL
+ || !DECL_TEMPLATE_SPECIALIZATION (newdecl)
+ || DECL_TEMPLATE_SPECIALIZATION (olddecl));
+
+ /* Copy all the DECL_... slots specified in the new decl except for
+ any that we copy here from the old type. */
+ if (merge_attr)
+DECL_ATTRIBUTES (newdecl)
+ = (*targetm.merge_decl_attributes) (olddecl, newdecl);
+ else
+DECL_ATTRIBUTES (olddecl) = DECL_ATTRIBUTES (newdecl);
if (DECL_DECLARES_FUNCTION_P (olddecl) && DECL_DECLARES_FUNCTION_P (newdecl))
{
@@ -2148,6 +2159,17 @@ next_arg:;
&& !tx_safe_fn_type_p (TREE_TYPE (newdecl)))
newtype = tx_unsafe_fn_variant (newtype);
+ if (!merge_attr)
+ {
+ /* Remove the two function attributes that are, in fact,
+ treated as (quasi) type attributes. */
+ tree attrs = TYPE_ATTRIBUTES (newtype);
+ tree newattrs = remove_attribute ("nonnull", attrs);
+ newattrs = remove_attribute ("returns_nonnull", attrs);
+ if (newattrs != attrs)
+ TYPE_ATTRIBUTES (newtype) = newattrs;
+ }
+
TREE_TYPE (newdecl) = TREE_TYPE (olddecl) = newtype;
if (TREE_CODE (newdecl) == FUNCTION_DECL)
@@ -2167,13 +2189,24 @@ next_arg:;
&& !(processing_template_decl && uses_template_parms (newdecl)))
layout_decl (newdecl, 0);
- /* Merge the type qualifiers. */
- if (TREE_READONLY (newdecl))
- TREE_READONLY (olddecl) = 1;
if (TREE_THIS_VOLATILE (newdecl))
TREE_THIS_VOLATILE (olddecl) = 1;
- if (TREE_NOTHROW (newdecl))
- TREE_NOTHROW (olddecl) = 1;
+
+ if (merge_attr)
+ {
+ /* Merge the type qualifiers. */
+ if (TREE_READONLY (newdecl))
+ TREE_READONLY (olddecl) = 1;
+ if (TREE_NOTHROW (newdecl))
+ TREE_NOTHROW (olddecl) = 1;
+ }
+ else
+ {
+ /* Set the bits that correspond to the const and nothrow
+ function attributes. */
+ TREE_READONLY (olddecl) = TREE_READONLY (newdecl);
+ TREE_NOTHROW (olddecl) = TREE_NOTHROW (newdecl);
+ }
/* Merge deprecatedness. */
