public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/33911] attribute deprecated vs. templates Date: Tue, 11 Nov 2014 14:18:00 -0000 [thread overview] Message-ID: <bug-33911-4-XGnVcfWs14@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-33911-4@http.gcc.gnu.org/bugzilla/> 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. =)
next prev parent reply other threads:[~2014-11-11 14:18 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-33911-4@http.gcc.gnu.org/bugzilla/> 2012-12-01 22:12 ` paolo.carlini at oracle dot com 2012-12-02 8:16 ` victor at enise dot org 2012-12-02 9:57 ` paolo.carlini at oracle dot com 2012-12-02 12:39 ` redi at gcc dot gnu.org 2013-10-01 0:06 ` eraman at google dot com 2013-10-03 17:39 ` eraman at gcc dot gnu.org 2014-11-11 14:18 ` redi at gcc dot gnu.org [this message] 2014-11-11 14:25 ` redi at gcc dot gnu.org 2014-11-11 17:52 ` jason at gcc dot gnu.org 2014-11-12 10:33 ` redi at gcc dot gnu.org 2014-11-13 3:06 ` redi at gcc dot gnu.org 2014-11-17 22:10 ` jason at gcc dot gnu.org 2022-03-02 15:51 ` ldionne.2 at gmail dot com 2007-10-26 15:08 [Bug c++/33911] New: " bkoz at gcc dot gnu dot org 2007-10-26 16:08 ` [Bug c++/33911] " pcarlini at suse dot de 2007-12-20 14:33 ` niemayer at isg dot de 2008-01-04 22:57 ` jason at redhat dot com 2008-05-02 21:41 ` jason at gcc dot gnu dot org 2008-12-28 3:25 ` pinskia at gcc dot gnu dot org 2009-11-05 23:09 ` jason at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-33911-4-XGnVcfWs14@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).