[Bug c++/33911] New: attribute deprecated vs. templates

[Bug c++/33911] New: attribute deprecated vs. templates

[bkoz at gcc dot gnu dot org]

In the following example, class "foo" gets a deprecated warning, but a similar
class template "goo" does not. Typedefs constructed with foo or goo get an
error.

What up?


struct foo
{
  int i;
} __attribute__ ((__deprecated__));

template<typename _Tp>
struct goo
{
  int i;
} __attribute__ ((__deprecated__));

typedef foo foo_type __attribute__ ((__deprecated__));
typedef goo<int> goo_type __attribute__ ((__deprecated__));


int main()
{
  foo f1;
  goo<int> f2;

  foo_type f3;
  goo_type f4;

  return 0;
}


I have a patch to mark the C++0x bits deprecated, but it's not working because
of this issue.


-- 
           Summary: attribute deprecated vs. templates
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bkoz at gcc dot gnu dot org
  GCC host triplet: all


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

[Bug c++/33911] attribute deprecated vs. templates

[pcarlini at suse dot de]

------- Comment #1 from pcarlini at suse dot de  2007-10-26 16:08 -------
*** Bug 33912 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

[Bug c++/33911] attribute deprecated vs. templates

[niemayer at isg dot de]

------- Comment #2 from niemayer at isg dot de  2007-12-20 14:32 -------
I can second that problem for template member functions - in contrast to
non-template member functions, where the attribute works.

This gives a warning about deprecation as expected:
-----------------------------------------------------------------
struct T { } ;

struct A {
        inline void foo(T & ) __attribute__((deprecated));
};

inline void A::foo(T & ) { }

void test(T & t) {
        A a;
        a.foo(t);
}
-------------------------------------------------------------

... while this is not causing a warning as it should:
-------------------------------------------------------------
struct A {
        template <class T> inline void foo(T & ) __attribute__((deprecated));
};

template <class T> inline void A::foo(T & ) { }

void test(A & t) {
        A a;
        a.foo(t);
}
-------------------------------------------------------------


-- 

niemayer at isg dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |niemayer at isg dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

[Bug c++/33911] attribute deprecated vs. templates

[jason at redhat dot com]

------- Comment #3 from jason at redhat dot com  2008-01-04 22:23 -------
Subject: Re:  attribute deprecated vs. templates

niemayer at isg dot de wrote:
> I can second that problem for template member functions - in contrast to
> non-template member functions, where the attribute works.

This is a parser bug: parsing the member template declaration winds up 
in cp_parser_init_declarator, which ignores attributes at the end of a 
declaration.  A normal member function goes through 
cp_parser_member_declaration, which handles the attributes properly. 
You can work around this bug by moving the attribute into the 
decl-specifier-seq, i.e. "void __attribute ((deprecated)) foo(T&)".

Jason


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

[Bug c++/33911] attribute deprecated vs. templates

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-05-02 21:41:07
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

[Bug c++/33911] attribute deprecated vs. templates

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2008-12-28 03:17 -------
*** Bug 36307 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sander at mi dot fu-berlin
                   |                            |dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

[Bug c++/33911] attribute deprecated vs. templates

[jason at gcc dot gnu dot org]

------- Comment #5 from jason at gcc dot gnu dot org  2009-11-05 23:08 -------
Not planning to work on this soon since there's a reasonable workaround.


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|jason at gcc dot gnu dot org|unassigned at gcc dot gnu
                   |                            |dot org
             Status|ASSIGNED                    |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

[Bug c++/33911] attribute deprecated vs. templates

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pashev.igor at gmail dot
                   |                            |com

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-12-01 22:12:13 UTC ---
*** Bug 55557 has been marked as a duplicate of this bug. ***

[Bug c++/33911] attribute deprecated vs. templates

[victor at enise dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

--- Comment #7 from Victor Gaydov <victor at enise dot org> 2012-12-02 08:16:04 UTC ---
I also have experienced bug 55557.

I'm porting a project that uses std::auto_ptr in several places to c++11.
However, there are no deprecated warnings because it happened that every unit
uses auto_ptr once.

If there is a workaround, may be it can be added to c++11 deprecated classes?

[Bug c++/33911] attribute deprecated vs. templates

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-12-02 09:56:41 UTC ---
Personally, I'm not aware of any wa, if somebody finds one, please add it here,
thanks.

[Bug c++/33911] attribute deprecated vs. templates

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-12-02 12:38:03 UTC ---
(In reply to comment #5)
> Not planning to work on this soon since there's a reasonable workaround.

Jason, that workaround is only for function templates, not class templates,
right?

It's odd that the warning works for class templates except on the first
instantiation (PR 55557)

[Bug c++/33911] attribute deprecated vs. templates

[eraman at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

Easwaran Raman <eraman at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eraman at google dot com

--- Comment #10 from Easwaran Raman <eraman at google dot com> ---
For template member functions, is concatenating the parsed attributes to
prefix_attributes and passing them to grokfield a valid fix? This patch works
for a small test case I have and I wonder if this is correct:

Index: gcc/cp/parser.c
===================================================================
--- gcc/cp/parser.c    (revision 202261)
+++ gcc/cp/parser.c    (working copy)
@@ -16489,7 +16489,7 @@ cp_parser_init_declarator (cp_parser* parser,
       decl = grokfield (declarator, decl_specifiers,
             initializer, !is_non_constant_init,
             /*asmspec=*/NULL_TREE,
-            prefix_attributes);
+            chainon (prefix_attributes, attributes));
       if (decl && TREE_CODE (decl) == FUNCTION_DECL)
     cp_parser_save_default_args (parser, decl);
     }

[Bug c++/33911] attribute deprecated vs. templates

[eraman at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

--- Comment #11 from eraman at gcc dot gnu.org ---
Author: eraman
Date: Thu Oct  3 17:39:35 2013
New Revision: 203174

URL: http://gcc.gnu.org/viewcvs?rev=203174&root=gcc&view=rev
Log:
2013-10-03  Easwaran Raman  <eraman@google.com>

        PR c++/33911
        * parser.c (cp_parser_init_declarator): Do not drop attributes
        of template member functions.

2013-10-03  Easwaran Raman  <eraman@google.com>

        PR c++/33911
        * g++.dg/ext/attribute47.C: New.



Added:
    trunk/gcc/testsuite/g++.dg/ext/attrib47.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/parser.c
    trunk/gcc/testsuite/ChangeLog

[Bug c++/33911] attribute deprecated vs. templates

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The comment below is from Richard Smith. I don't think we do have the same
problem for abi_tag, so Jason must have solved this problem there.

--------

I was amazed to discover that clang has the *exact* same bug as gcc:

template<typename T> struct S {} __attribute__((deprecated));
S<int> s1; // no warning
S<int> s2; // warning, deprecated

Moving the attribute earlier makes no difference to either compiler.

And... I can tell you exactly why this is happening: when we see the use of
S<int>, we instantiate the declaration. That does not instantiate attributes.
The use is checked, it's not marked deprecated, so no warning occurs.

Then we perform initialization of s1. That triggers the instantiation of the
definition and the attribute. But we don't use the name S<int> here; that
already happened earlier.

Finally, we use S<int> again in the declaration of s2, and now we have both a
use and an attribute, so we warn.

I'm not entirely sure what the right resolution is here. Maybe some attributes
should be instantiated when we instantiate a class template specialization
declaration, rather than delaying all of them until we instantiate the
definition. I expect that your abi_tag attribute has the same bug, by the way,
and if you never trigger the instantiation of the definition of
basic_string<T>, then that type won't get an ABI tag. =)

[Bug c++/33911] attribute deprecated vs. templates

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Also, even after the template definition (and the attribute) have been
instantiated, typedefs for the instantiation don't get a warning unless the
typedef itself is also marked deprecated:

template<typename T> struct S {} __attribute__((deprecated));
using Si = S<int>;
using Sd __attribute__((deprecated)) = S<int>;
S<int> s1; // no warning
S<int> s2; // warning, deprecated
Si s3; // no warning
Sd s4; // warning, deprecated

This means that users with a typedef for std::auto_ptr<int> will never get the
warning, because libstdc++ can only add the attribute to the primary template,
not to users' own typedefs.

This matters more now because WG21 just voted to remove auto_ptr from C++17 so
we really want the deprecated attributes in libstdc++ to issue warnings.

[Bug c++/33911] attribute deprecated vs. templates

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

--- Comment #14 from Jason Merrill <jason at gcc dot gnu.org> ---
Created attachment 33938
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33938&action=edit
patch

Here's a compiler patch.  Jonathan, can you decide what to do with the library
testsuite regressions it introduces and check it in?

[Bug c++/33911] attribute deprecated vs. templates

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Author: redi
Date: Wed Nov 12 10:32:17 2014
New Revision: 217412

URL: https://gcc.gnu.org/viewcvs?rev=217412&root=gcc&view=rev
Log:
Add -Wno-deprecated to dg-options.

    PR c++/33911
    * testsuite/20_util/shared_ptr/assign/auto_ptr.cc: Use -Wno-deprecated.
    * testsuite/20_util/shared_ptr/assign/auto_ptr_neg.cc: Likewise.
    * testsuite/20_util/shared_ptr/cons/43820_neg.cc: Likewise.
    * testsuite/20_util/shared_ptr/cons/auto_ptr.cc: Likewise.
    * testsuite/20_util/shared_ptr/cons/auto_ptr_neg.cc: Likewise.
    * testsuite/20_util/unique_ptr/cons/auto_ptr.cc: Likewise.
    * testsuite/20_util/unique_ptr/cons/auto_ptr_neg.cc: Likewise.
    * testsuite/ext/array_allocator/variadic_construct.cc: Likewise.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/testsuite/20_util/shared_ptr/assign/auto_ptr.cc
    trunk/libstdc++-v3/testsuite/20_util/shared_ptr/assign/auto_ptr_neg.cc
    trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/43820_neg.cc
    trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/auto_ptr.cc
    trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/auto_ptr_neg.cc
    trunk/libstdc++-v3/testsuite/20_util/unique_ptr/cons/auto_ptr.cc
    trunk/libstdc++-v3/testsuite/20_util/unique_ptr/cons/auto_ptr_neg.cc
    trunk/libstdc++-v3/testsuite/ext/array_allocator/variadic_construct.cc

[Bug c++/33911] attribute deprecated vs. templates

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I've fixed most of the tests but I think the remaining ones reveal that the
warning is a bit too eager:

template<typename T>
struct B
{
  B(T t) { }

} __attribute__ ((__deprecated__));

template<typename T>
B<T> b(T t)
{
  return B<T>(t);
}

int main()
{
}

dep.cc:9:11: warning: ‘B’ is deprecated (declared at dep.cc:2)
[-Wdeprecated-declarations]
 B<T> b(T t)
           ^
dep.cc: In function ‘B<T> b(T)’:
dep.cc:11:16: warning: ‘B’ is deprecated (declared at dep.cc:2)
[-Wdeprecated-declarations]
   return B<T>(t);
                ^

The warning comes even when b() isn't instantiated and can't be disabled with a
#pragma.

I have no idea why this only affects 3 tests, not all the -std=gnu++11 tests,
so maybe I should just add -D_GLIBCXX_USE_DEPRECATED=0 to the dg-options for
those three tests to prevent the deprecated components being included.
>From gcc-bugs-return-466601-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Nov 13 03:55:13 2014
Return-Path: <gcc-bugs-return-466601-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18844 invoked by alias); 13 Nov 2014 03:55:12 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18814 invoked by uid 48); 13 Nov 2014 03:55:07 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/63843] [5 Regression] wrong code generation at -O1 and higher
Date: Thu, 13 Nov 2014 03:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on target_milestone short_desc everconfirmed
Message-ID: <bug-63843-4-2VDr7anxxn@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63843-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63843-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg01073.txt.bz2
Content-length: 738

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc843

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-13
   Target Milestone|---                         |5.0
            Summary|wrong code generation at    |[5 Regression] wrong code
                   |-O1 and higher              |generation at -O1 and
                   |                            |higher
     Ever confirmed|0                           |1

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
It is caused by r217118.

[Bug c++/33911] attribute deprecated vs. templates

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

--- Comment #17 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Mon Nov 17 22:09:27 2014
New Revision: 217677

URL: https://gcc.gnu.org/viewcvs?rev=217677&root=gcc&view=rev
Log:
    PR c++/33911
gcc/cp/
    * call.c (build_call_a): Don't warn_deprecated_use here.
    (build_over_call): Or here.
    * decl2.c (mark_used): Do it here.
    (is_late_template_attribute): Attribute deprecated is not deferred.
    (cplus_decl_attributes): Propagate TREE_DEPRECATED out to the template.
    * parser.c (cp_parser_template_name): Warn about deprecated template.
    (cp_parser_template_argument): Likewise.
libstdc++-v3/
    * include/backward/binders.h: Suppress -Wdeprecated-declarations.
    * include/ext/array_allocator.h: Likewise.

Added:
    trunk/gcc/testsuite/g++.dg/ext/attr-deprecated-1.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/call.c
    trunk/gcc/cp/decl2.c
    trunk/gcc/cp/parser.c
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/backward/binders.h
    trunk/libstdc++-v3/include/ext/array_allocator.h

[Bug c++/33911] attribute deprecated vs. templates

[ldionne.2 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911

Louis Dionne <ldionne.2 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ldionne.2 at gmail dot com

--- Comment #21 from Louis Dionne <ldionne.2 at gmail dot com> ---
(In reply to Martin Sebor from comment #20)
> (In reply to Jonathan Wakely from comment #16)
> 
> Although Clang doesn't, warning for uses of a deprecated primary seems
> correct/useful to me because there's no way to define a specialization of
> the primary that's not deprecated.  In your test case, there is no
> specialization of  b() that would not use some specialization of the primary
> class template, and since every specialization is a use of the primary, that
> would not be subject to its deprecated attribute.  (It seems analogous to
> warning for an unused constexpr function that can never be used in a core
> constant expression.)

I believe it is important to *not* diagnose when the template is never
instantiated. Indeed, imagine a library is providing these declarations. It
needs to keep them around for backwards compatibility, but it also wants to
mark them as deprecated to make sure that no users actually use them.

With the current state of affairs, GCC will issue a warning just because the
declarations exist and are marked as deprecated, even if the user doesn't
actually use these declarations. This is not useful behavior -- it ends up
being so noisy that the only reasonable solution is to remove deprecation
warnings altogether, which defeats the whole thing. This is exactly what we're
hitting with libc++ on GCC right now. I think it would be worth reconsidering
the resolution of this issue to make GCC's behavior match Clang's behavior more
closely.

> If you feel it's important to only warn for code that's instantiated, rather
> than reopening this bug I suggest opening a separate bug just for that.

See https://gcc.gnu.org/PR104760.