[Bug c++/51930] New: Explicitly instantiated template gets hidden visibility

[Bug c++/51930] New: Explicitly instantiated template gets hidden visibility

[sefi@s-e-f-i.de]

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

             Bug #: 51930
           Summary: Explicitly instantiated template gets hidden
                    visibility
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: sefi@s-e-f-i.de


gcc-4.7 produces a symbol with hidden visibility for testfunc<foo>, while
gcc-4.6 produces a symbol with default visibility.

struct foo
{
};

template<
        typename T
>
__attribute__ ((visibility("default")))
void testfunc();

template<
        typename T
>
void testfunc()
{
}

template
__attribute__ ((visibility("default")))
void testfunc<foo>();


I compiled this with 
g++-4.7 -fvisibility=hidden -shared test.cpp


If I replace

struct foo {};

with 

struct __attribute__ ((visibility("default"))) foo {};

then testfunc<foo> gets default visibility even with gcc-4.7.

Is this intentional?

[Bug c++/51930] Explicitly instantiated template gets hidden visibility

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-21 14:04:39 UTC ---
(In reply to comment #0)
> Is this intentional?

I think so, see PR 35688

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-21
            Summary|Explicitly instantiated     |[4.7 regression] Explicitly
                   |template gets hidden        |instantiated template gets
                   |visibility                  |hidden visibility
     Ever Confirmed|0                           |1

--- Comment #2 from Jason Merrill <jason at gcc dot gnu.org> 2012-01-21 20:26:03 UTC ---
The explicit visibility on the explicit instantiation should cause it to have
default visibility; without that it should have hidden visibility.

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

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

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill <jason at gcc dot gnu.org> 2012-01-23 20:48:35 UTC ---
Author: jason
Date: Mon Jan 23 20:48:31 2012
New Revision: 183455

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183455
Log:
    PR c++/51930
    * decl2.c (determine_visibility): Check for visibility attribute
    on template specialization.

Added:
    trunk/gcc/testsuite/g++.dg/ext/visibility/template10.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/decl2.c
    trunk/gcc/testsuite/ChangeLog

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #4 from Jason Merrill <jason at gcc dot gnu.org> 2012-01-23 20:56:43 UTC ---
Fixed.

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[sefi@s-e-f-i.de]

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

Philipp <sefi@s-e-f-i.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #5 from Philipp <sefi@s-e-f-i.de> 2012-01-29 12:19:48 UTC ---
Thanks, Jason, the above test case now works.
However, a similar problem with explicitly instantiated template classes still
exists.
Here is a test case.

struct test
{
};

template<
        typename T
>
struct template_test
{
        __attribute__((visibility("default")))
        void function();
};

template<
        typename T
>
void template_test<T>::function()
{
}

template
__attribute__((visibility("default")))
struct template_test<test>;

With gcc-4.7, template_test<test>::function gets hidden visibility, while with
gcc-4.6.2 it gets default visibility.

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill <jason at gcc dot gnu.org> 2012-02-15 01:22:43 UTC ---
The problem here is that there is currently no way to add attributes to a class
template instantiation; on the explicit instantiation in your testcase the
attributes are just ignored.

Wouldn't it be easier to just give test default visibility?

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[sefi@s-e-f-i.de]

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

--- Comment #7 from Philipp <sefi@s-e-f-i.de> 2012-02-15 09:29:27 UTC ---
The test struct might come from an external library I have no control of, which
will make it difficult to change its visibility. Currently, I have quite some
code that depends on the behaviour of gcc-4.6 and lower that won't be easy to
change.

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-15 10:15:06 UTC ---
(In reply to comment #7)
> The test struct might come from an external library I have no control of, which
> will make it difficult to change its visibility.

You could declare the struct before including that library's headers and set
its visibility with a pragma:

#pragma GCC visibility push(default)
struct test;
#pragma GCC visibility pop

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill <jason at gcc dot gnu.org> 2012-02-15 10:53:37 UTC ---
(In reply to comment #8)
> You could declare the struct before including that library's headers and set
> its visibility with a pragma:
> 
> #pragma GCC visibility push(default)
> struct test;
> #pragma GCC visibility pop

Or just wrap the #include in these pragmas.  If the instantiation needs to have
default visibility, presumably the library has default visibility and so should
its header.

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[sefi@s-e-f-i.de]

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

--- Comment #10 from Philipp <sefi@s-e-f-i.de> 2012-02-15 12:02:09 UTC ---
But think about a header only library. My test case isn't that far fetched. A
simple struct with no member functions (except for the implicitly generated
ones) should need no visibility at all, in my opinion.
I can work around this somehow, but wouldn't it be better to fix it?

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-02-15 13:50:07 UTC ---
("...  wouldn't it be better to fix it?" should read "... to change it?",
otherwise you are begging the question, eh)

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill <jason at gcc dot gnu.org> 2012-02-16 08:23:38 UTC ---
(In reply to comment #10)
> But think about a header only library. My test case isn't that far fetched. A
> simple struct with no member functions (except for the implicitly generated
> ones) should need no visibility at all, in my opinion.

Sure, but then why do you want the instantiation to have higher visibility?  It
doesn't make sense to me for a function that has that type in the signature to
have higher visibility than the type itself.

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.7.0

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |WAITING

--- Comment #13 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-27 10:38:03 UTC ---
This seems to be still a regression.  If we decide the new behavior is desired
can someone work on better documenting the effects of visibility and template
instantiations?

And, is this "regression" now desired?  Otherwise a wrong-code regression
would be P1.

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[sefi@s-e-f-i.de]

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

--- Comment #14 from Philipp <sefi@s-e-f-i.de> 2012-02-27 11:06:20 UTC ---
The new behaviour makes it pretty much impossible for me to retain the
visibility gcc has been giving me with the old behaviour.

It is impossible to only give every type that is somehow involved in a template
instantiation (and a lot of them happen to be simple typedef helper structs)
default visibility. A lot of them come from external libraries I have no
control over. I have tried and gave up after some hours.

The push/pop visibility can be done, if one is very careful. Doing this on a
fine grained level is out of the question. You know how C++ includes and their
include guards work. You have to put the push/pop macros around the first
inclusion of such a header, which is almost never possible. If you decide to go
for a wider push/pop scope (for example all the headers in the TU that does the
explicit instantiation(s)) then you might end up giving a lot of stuff default
visibility that you don't want to.
Even if this method would succeed, it would still mean a lot of extra macro
invocations just for gcc-4.7.

Please, I don't know how to properly deal with this, and would like the old
behaviour to be restored.

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-27 14:56:13 UTC ---
(In reply to comment #14)
> The new behaviour makes it pretty much impossible for me to retain the
> visibility gcc has been giving me with the old behaviour.

The old behaviour was buggy,

> The push/pop visibility can be done, if one is very careful. Doing this on a
> fine grained level is out of the question. You know how C++ includes and their
> include guards work. You have to put the push/pop macros around the first
> inclusion of such a header, which is almost never possible. If you decide to go
> for a wider push/pop scope (for example all the headers in the TU that does the
> explicit instantiation(s)) then you might end up giving a lot of stuff default
> visibility that you don't want to.

You could write forwarding headers for the third-party headers and put them
earlier in your include path with -I 
e.g. for foo.h

#pragma GCC visibility push(default)
#include_next <foo.h>
#pragma GCC visibility push

> Even if this method would succeed, it would still mean a lot of extra macro
> invocations just for gcc-4.7.

If you don't want to use that header for older versions of GCC just don't put
the directory with the forwarding headers in the include path.

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-27 15:07:28 UTC ---
(In reply to comment #15)
> #pragma GCC visibility push(default)
> #include_next <foo.h>
> #pragma GCC visibility push

Oops, should be pop, obviously

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |FIXED

--- Comment #17 from Jason Merrill <jason at gcc dot gnu.org> 2012-03-01 02:38:28 UTC ---
(In reply to comment #6)
> The problem here is that there is currently no way to add attributes to a class
> template instantiation

Oops, I was wrong.  The problem was that you just had the attribute in the
wrong position; it needs to come between the "struct" and the class name, i.e.

template
struct __attribute__((visibility("default")))
template_test<test>;

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[jason at gcc dot gnu.org]

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

--- Comment #18 from Jason Merrill <jason at gcc dot gnu.org> 2012-03-01 17:52:18 UTC ---
Author: jason
Date: Thu Mar  1 17:52:12 2012
New Revision: 184753

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184753
Log:
    PR c++/51930
    * decl.c (check_tag_decl): Move warning for misplaced attributes here.
    (shadow_tag): From here.
    * parser.c (cp_parser_explicit_instantiation): Don't warn here.

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

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #19 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-03-01 20:47:58 UTC ---
(In reply to comment #18)
> Author: jason
> Date: Thu Mar  1 17:52:12 2012
> New Revision: 184753

No new testcase?

+    input_location = location_of (declared_type);
+      warning (0, "attribute ignored in declaration of %q#T", declared_type);
+      warning (0, "attribute for %q#T must follow the %qs keyword",
+           declared_type, class_key_or_enum_as_string (declared_type));
+      input_location = loc;

Wouldn't it be simple and clearer to use warning_at(location) ?

And the second warning should be inform.

And given:

-      if (decl_specifiers.attributes)
-    warning (OPT_Wattributes,
-         "attributes ignored on explicit type instantiation");

It is clear that the behavior is not equivalent. The warning before was
conditional on -Wattributes, but now it is unconditional. Was this intentional?

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[manu at gcc dot gnu.org]

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

--- Comment #20 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-03-01 20:53:41 UTC ---
(In reply to comment #19)
> It is clear that the behavior is not equivalent. The warning before was
> conditional on -Wattributes, but now it is unconditional. Was this intentional?

Since Wattributes is on by default, it cannot hurt to make the warning
conditional on it.

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[jason at gcc dot gnu.org]

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

--- Comment #21 from Jason Merrill <jason at gcc dot gnu.org> 2012-03-05 18:09:08 UTC ---
Author: jason
Date: Mon Mar  5 18:08:56 2012
New Revision: 184946

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184946
Log:
    PR c++/51930
    * decl2.c (determine_visibility): Correct calculation of class
    args depth.
    * decl.c (check_tag_decl): Adjust warning.

Added:
    trunk/gcc/testsuite/g++.dg/ext/visibility/template11.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/decl.c
    trunk/gcc/cp/decl2.c
    trunk/gcc/testsuite/ChangeLog