On 8/30/24 1:34 PM, Jakub Jelinek wrote:
On Mon, Aug 19, 2024 at 05:05:51PM -0400, Jason Merrill wrote:
I've tried to compile it also with latest clang and there is agreement in
most of the diagnostics, just at block scope (inside of foo) it doesn't
diagnose
    auto e = new int [n] [[deprecated]];
    auto e2 = new int [n] [[deprecated]] [42];
    [[deprecated]] lab:;
and at namespace scope
[[deprecated]];
I think that all feels like clang++ bug.
On the other side, clang++ diagnoses
enum B { B0 } [[deprecated]];
but GCC with all the patches I've posted today doesn't, is that a GCC bug?

I think so, yes.

Fixed in the just posted 2 patches.

The FIXMEs are where there is agreement with clang++, but I'm not sure.
One thing is I'm not sure if "a variable" above is meant to include function
parameters, and/or unused function parameters without a specified name,
function parameters inside of a function declaration rather than definition
and/or static data members.

All of those, I believe.

Removed the FIXMEs.

Also unsure about
    [[deprecated]] int : 0;
at class scope, that isn't a non-static data member...

Indeed, pedantically the standard says it can't apply to an unnamed
bit-field.

And the following updated version on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661904.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661905.html
patches also diagnoses the attribute on unnamed bit-fields.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2024-08-30  Jakub Jelinek  <ja...@redhat.com>

        PR c++/110345
        * parser.cc (cp_parser_std_attribute): Don't transform
        [[deprecated]] into [[gnu::deprecated]].
        * tree.cc (handle_std_deprecated_attribute): New function.
        (std_attributes): Add deprecated entry.

        * g++.dg/cpp0x/attr-deprecated1.C: New test.

--- gcc/cp/parser.cc.jj 2024-08-30 11:13:18.612089567 +0200
+++ gcc/cp/parser.cc    2024-08-30 12:55:17.875362909 +0200
@@ -30357,12 +30357,11 @@ cp_parser_std_attribute (cp_parser *pars
/* We used to treat C++11 noreturn attribute as equivalent to GNU's,
         but no longer: we have to be able to tell [[noreturn]] and
-        __attribute__((noreturn)) apart.  */
-      /* C++14 deprecated attribute is equivalent to GNU's.  */
-      if (is_attribute_p ("deprecated", attr_id))
-       TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
+        __attribute__((noreturn)) apart.
+        Similarly for C++14 deprecated attribute, we need to emit extra
+        diagnostics for [[deprecated]] compared to [[gnu::deprecated]].  */
        /* C++17 fallthrough attribute is equivalent to GNU's.  */
-      else if (is_attribute_p ("fallthrough", attr_id))
+      if (is_attribute_p ("fallthrough", attr_id))
        TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
        /* C++23 assume attribute is equivalent to GNU's.  */
        else if (is_attribute_p ("assume", attr_id))
--- gcc/cp/tree.cc.jj   2024-08-15 22:23:07.908239976 +0200
+++ gcc/cp/tree.cc      2024-08-30 13:15:26.863829810 +0200
@@ -5087,6 +5087,25 @@ handle_likeliness_attribute (tree *node,
      return error_mark_node;
  }
+/* The C++14 [[deprecated]] attribute mostly maps to the GNU deprecated
+   attribute.  */
+
+static tree
+handle_std_deprecated_attribute (tree *node, tree name, tree args, int flags,
+                                bool *no_add_attrs)
+{
+  tree t = *node;
+  tree ret = handle_deprecated_attribute (node, name, args, flags,
+                                         no_add_attrs);
+  if (TYPE_P (*node) && t != *node)
+    pedwarn (input_location, OPT_Wattributes,
+            "%qE on a type other than class or enumeration definition", name);
+  else if (TREE_CODE (*node) == FIELD_DECL && DECL_UNNAMED_BIT_FIELD (*node))
+    pedwarn (input_location, OPT_Wattributes, "%qE on unnamed bit-field",
+            name);

Why not warn about these for the GNU deprecated attribute as well?

Jason

Reply via email to