[Bug c++/19664] New: -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

[Bug c++/19664] New: -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

[andreas dot pokorny at gmx dot de]

Failing code:
template<typename CharT>
struct VisTest
{
  inline VisTest ();
};
template<typename CharT>
inline VisTest<CharT>::VisTest()
{}
extern template class VisTest<char>;  // It works if we drop that line
int some_function( int do_something ) __attribute__ ((visibility("default")));
int some_function( int do_something )
{
  VisTest<char> a;
  return 0;
}

g++ -fPIC -fvisibility=hidden -fvisibility-inlines-hidden lib.cpp -c
g++ -shared -fPIC  -fvisibility=hidden -fvisibility-inlines-hidden lib.o -o
liblib.so

/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.0/../../../../x86_64-pc-linux-gnu/bin/ld:
lib.o: relocation R_X86_64_PC32 against `VisTest<char>::VisTest()' can not be
used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.0/../../../../x86_64-pc-linux-gnu/bin/ld:
final link failed: Bad value
collect2: ld returned 1 exit status

This happens with nearly all cases in which libstdc++ headers are involved:
http://bugs.gentoo.org/show_bug.cgi?id=78720
http://groups.google.de/groups?q=relocation+R_X86_64_PC32+against+making+a+shared+object&hl=de&lr=&selm=ct12kj%242njo%241%40FreeBSD.csie.NCTU.edu.tw&rnum=2

-- 
           Summary: -fvisibility-inlines-hidden fails with gcc's extern
                    template extension on amd64
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: andreas dot pokorny at gmx dot de
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug c++/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-01-28 09:56 -------
Thanks for the nice testcase. Is this really a GCC bug, or a binutils bug:

  http://bugs.gentoo.org/show_bug.cgi?id=79711

???

-- 


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

[Bug c++/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

[lanius at gentoo dot org]

------- Additional Comments From lanius at gentoo dot org  2005-01-28 13:02 -------
It may be related to this change in binutils: 
 
http://sources.redhat.com/ml/libc-alpha/2004-12/msg00062.html 
 
Changes from binutils 2.15.91.0.1: 
2. Fix the x86_64 linker to prevent non-PIC code in shared library. 

-- 


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

[Bug c++/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

[lanius at gentoo dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lanius at gentoo dot org


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

[Bug c++/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-01-28 13:13 -------
I think HJ may be interested...

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl at lucon dot org


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

[Bug c++/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

[simon dot strandman at telia dot com]

------- Additional Comments From simon dot strandman at telia dot com  2005-01-28 13:35 -------
>Thanks for the nice testcase. Is this really a GCC bug, or a binutils bug:
>
>http://bugs.gentoo.org/show_bug.cgi?id=79711

Downgrading binutils from 2.15.92.0.2 to 2.15.90.0.1.1 fixed the compilation for
all KDE packages except kdepim. But kdepim failed with another probably not
related error.

-- 


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

[Bug target/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |target
  GCC build triplet|x86_64-pc-linux-gnu         |
   GCC host triplet|x86_64-pc-linux-gnu         |


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

[Bug target/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2005-01-29 01:05 -------
It is a compiler bug. VisTest<char>::VisTest() is never defined.
R_X86_64_PC32 relocation may not reach it at runtime when it is
called. The new linker catches this particular bug at linktime.

-- 


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

[Bug target/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 13:05 -------
(In reply to comment #5)
> It is a compiler bug. VisTest<char>::VisTest() is never defined.
> R_X86_64_PC32 relocation may not reach it at runtime when it is
> called. The new linker catches this particular bug at linktime.

Actually this is not a gcc or a linker bug but a programmers.
Basically -fvisibility=hidden -fvisibility-inlines-hidden says all I repeat all functions (defined or not) as 
hidden.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug target/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

[andreas dot pokorny at gmx dot de]

------- Additional Comments From andreas dot pokorny at gmx dot de  2005-01-29 15:08 -------
If it is a programmers bug, why does it happen only with amd64, but not with
ia32 or ia64?

>  Actually this is not a gcc or a linker bug but a programmers.
>  Basically -fvisibility=hidden -fvisibility-inlines-hidden says all I repeat
all functions (defined or not) 
>  as hidden.

This does not explain why gcc should fail to create the library. In my opinion
the programmer isnt the one to blame, he declared a strucutre, which should not
be exported to the library, and a function that should be exported. Within his
library he uses that structure, whats wrong about that? 

-- 


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

[Bug target/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

[andreas dot pokorny at gmx dot de]

------- Additional Comments From andreas dot pokorny at gmx dot de  2005-01-29 15:26 -------
I am also refereing to this example: 
http://gcc.gnu.org/ml/libstdc++/2005-01/msg00300.html


-- 


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

[Bug target/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 15:28 -------
(In reply to comment #8)
> I am also refereing to this example: 
> http://gcc.gnu.org/ml/libstdc++/2005-01/msg00300.html

Now there is a libstdc++ bug for not using pop/push of the visibility in the headers which is not what I 
orginally thought this bug was about.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 15:32 -------
(In reply to comment #9)
> (In reply to comment #8)
> > I am also refereing to this example: 
> > http://gcc.gnu.org/ml/libstdc++/2005-01/msg00300.html
> 
> Now there is a libstdc++ bug for not using pop/push of the visibility in the headers which is not what 
> I orginally thought this bug was about.

If you actually commented saying that this came from libstdc++ and then I would have commented 
saying that there needs some push/pop in the headers but instead you gave a simplified example which 
is not a gcc/linker bug but a programmers mistake.

Confirmed, changing the summary to match the correct the sumbitter's mistake of not giving the full 
story.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|target                      |libstdc++
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-01-29 15:32:29
               date|                            |
            Summary|-fvisibility-inlines-hidden |libstdc++ headers should
                   |fails with gcc's extern     |have pop/push of the
                   |template extension on amd64 |visibility around the
                   |                            |declarations


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 15:37 -------
Note the orginal testcase is:
#include <string> 
int some_function( std::string const& do_something ) __attribute__ ((visibility("default")));

int some_function( std::string const& do_something ) 
{
  std::string another_string;
  return 0;
}


-- 


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

[Bug target/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[andreas dot pokorny at gmx dot de]

------- Additional Comments From andreas dot pokorny at gmx dot de  2005-01-29 16:24 -------
I am sorry, in my attempt to reduce the exmaple I introduced a bug in the testcase. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libstdc++                   |target


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 16:26 -------
(In reply to comment #12)
> I am sorry, in my attempt to reduce the exmaple I introduced a bug in the testcase. 
Yes and this is not a target related bug at all but a libstdc++ one.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
          Component|target                      |libstdc++


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-01-29 20:52 -------
Interesting ;) After so many months, it turns out we have to add push/pop to
*all* the headers?!? Why nobody mentioned that before?!? Not a big deal, in case,
but I'm somewhat suprised.

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-01-31 10:32 -------
Ok, now I see the issue clearly:

  http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00114.html

In particular:

  "I did not attempt to fix all of the V3 headers; I'm only concerned
  with libsupc++ at the moment. However, similar changes should
  probably be made throughout V3. Otherwise, linkage will be wrong if
  people #include (say) <iostream> with a non-default symbol visibility."

Will fix this.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
                   |dot org                     |
             Status|NEW                         |ASSIGNED


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-01-31 18:57 -------
Adding pragma visibility push(default)/pop to the basic_string.h header (or to
the std_string.h header, for that matter) does *not* fix the issue for me. Is
anyone able to confirm this or viceversa? (binutils 2.15.91.0.2 on x86_64)

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-02-02 13:51 -------
By the way: if this is really a generic problem in libstdc++, why I cannot
reproduce it on x86? There, I'm using mainline as of February, 1 + binutils
2.15.94.0.2.

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-02-02 16:01 -------
Hummm:

  http://sources.redhat.com/ml/binutils/2005-01/msg00511.html



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aj at suse dot de


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2005-02-02 16:09 -------
My linker patch is for PROTECTED function symbols. It tries to prevent

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

BTW, R_X86_64_PC32 CAN NOT be used for global symbols since it is only 32bit
while the address space is 64bit. x86 doesn't have this issue.

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-02-02 16:16 -------
> My linker patch is for PROTECTED function symbols. It tries to prevent
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520

Ok, just checked the testcase in binutils/584.

> BTW, R_X86_64_PC32 CAN NOT be used for global symbols since it is only 32bit
> while the address space is 64bit. x86 doesn't have this issue.

OK, noted. Now, why:
1- Adding visibility push(default)/pop to the library does *not* help on
   x86_64 for this (comment #11) testcase?
2- Why visibility push(default)/pop are necessary only on x86_64?!?

Sorry, two naive questions, but really before delving in the technical
details I want to be sure that overall things are consistent.


-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-02-02 16:25 -------
In other terms, I understand this

> BTW, R_X86_64_PC32 CAN NOT be used for global symbols since it is only 32bit
> while the address space is 64bit. x86 doesn't have this issue.

as meaning that the compiler should *not* emit R_X86_64_PC32 in the first place,
irrespective od other "details" affecting the c++ library. Thus, a *compiler*
bug, certainly.

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2005-02-02 17:17 -------
I believe it is a real compiler bug. I will see what I can do.

-- 


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

[Bug c/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[giovannibajo@libero.it]

------- Additional Comments From giovannibajo at libero dot it  2005-02-06 13:11 -------
So this is both a compiler bug and a v3 bug. HJL provided a patch for the C++ 
frontend here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html
Notice that the patch is incomplete because it is missing a testcase.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch


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

[Bug c/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pcarlini@suse.de]

------- Additional Comments From pcarlini at suse dot de  2005-02-06 13:19 -------
A testcase suitably distilled from #11 should do.

For the libstdc++ side of the problem, we are missing a testcase. Probably, it's
better opening a separate, complete libstdc++ PR: then fixing the latter will be
straightforward (just add push/pop everywhere, I have a draft ready).

-- 


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

[Bug c/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pcarlini@suse.de]

------- Additional Comments From pcarlini at suse dot de  2005-02-06 13:22 -------
But, on second thought, sorry, I think we have also a third problem, target
dependent, for R_X86_64_PC32 relocaltions wrongly emitted for global symbols
on x86_64.

-- 


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

[Bug c/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pcarlini@suse.de]

------- Additional Comments From pcarlini at suse dot de  2005-02-06 13:24 -------
Actually, the testcase in comment #11 is about the *third* issue, AFAICS.

-- 


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

[Bug c/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[hjl@lucon.org]

------- Additional Comments From hjl at lucon dot org  2005-02-06 16:23 -------
I don't think emitting R_X86_64_PC32 is a bug since
-fvisibility=hidden -fvisibility-inlines-hidden is
used and the undefined function can be defined in
another .o file. The real bug is gcc doesn't emit

     .hidden foo

when foo is marked hidden and undefined.




-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2005-02-08 01:14 -------
The testcase patch is at

http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00287.html

To properly support -fvisibility-inlines-hidden, ASM_OUTPUT_EXTERNAL
should be defined. We can collected undefined symbols with non-default
visibility and generate the assmebly directives in TARGET_ASM_FILE_END.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |libstdc++


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[bkoz at gcc dot gnu dot org]

------- Additional Comments From bkoz at gcc dot gnu dot org  2005-02-25 22:40 -------

Personally, I think the better approach for the libstdc++ parts is to allow
__attribute__ visibility on namespace declarations.

That way, all this goo could be removed, and centralized in one place. Ie,
c++config.h could have something like:

namespace std __attribute__ ((visibility ("default") ));
{
 
}


And volia! We are done.

(When I first saw this, I thought that the solution being proposed was mass
decoration of std:: names with some kind of pseudo-__declspec bullshit. Of
course, that is a non-starter, so I'm glad to see the thinking has evolved a bit.)

-benjamin





-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bkoz at gcc dot gnu dot org


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-02-26 23:45 -------
HJL: would you please open a different bug report for the x86-64 issue and 
link it to this bug?

Benjamin: can you open a different enhancement proposal about supporting the 
visibility attribute at namespace-level? Anyway, I think the correct way to go 
for 4.0 is to use the pragmas. A patch against the 4.0 branch would be much 
appreciated.

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2005-02-27 03:54 -------
There are 3 bugs here:

1. libstdc++ should have pop/push of the visibility.
2. C++ should support pop/push of the visibility.
3. Gcc should emit ".hidden foo" when foo is marked hidden, defined or not.

Patches for #2 are at

http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00287.html

I opened a bug for #3, bug 20218.


-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[matz at suse dot de]

------- Additional Comments From matz at suse dot de  2005-04-18 12:49 -------
So, any progress on this whole issue?  I don't see either the pragmas in the 
C++ headers, nor HJs changes to the c++ frontend (despite testcase) in CVS. 
 
Just for the record, I see these problems (linkproblem with test from 
comment #11) also on ppc and ppc64, so it's not 
just a target dependend problem.  On ppc64 it's an unresolvable R_PPC64_REL24 
relocation, and on ppc it's simply an undefined reference to the std::string 
ctor. 

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[matz at suse dot de]

------- Additional Comments From matz at suse dot de  2005-04-18 12:50 -------
Oh, and just annotating the testcase with the visibility push/pop #pragma 
is not enough, probably because of the problem in the c++ frontend, HJ noted. 

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-04-18 14:14 -------
Hi Michael and thanks for asking: really, I'm lost in this tangle of front-end,
back-end and library issues. When I'm back from Oxford really want to move the
issue forward, somehow, asking all the knowledgeable people (besides doing 
myself the, rather trivial, it seems, library bits). In the meanwhile, if you
are able to see clearly which front-end/back-end patches among all those proposed
here and posted on gcc-patches are *definitely* improvements, please patronize
and ping on gcc-patches...

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2005-05-04 17:15 -------
*** Bug 21382 has been marked as a duplicate of this bug. ***

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-05-17 19:05 -------
> This patch looks sensible to me, but it should be approved by a V3 
> maintainer.

Thanks a lot Mark, I'll try to get to it soon. But, the real reason we don't
have those bits already is that there are outstanding front-end issues that
apparently nobody cares about. Can you possible have a look to my last 
summary of the situation:

  http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00275.html

???

Notice that in the meanwhile HJ posted/attached an updated patch for 20218.

Do we at least agree that these are real bugs? Who is in charge of maintaining
this visibility stuff? I'm finding the situation wrt to those visibility
issues a little puzzling: apparently is a nice feature that we all want, but,
on the other hand, nobody pays attention to those long-standing bug reports.

Sorry about the rant ;)

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pluto at agmk dot net]

------- Additional Comments From pluto at agmk dot net  2005-05-17 21:39 -------
(In reply to comment #44)   
   
I've tested PR19664 patch + updated PR20218 patch + v3 patch   
and they work fine on amd64. I'll test fixes soon on powerpc  
on testcase from PR21382 too. 

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2005-05-17 21:40 -------
Subject: Re:  libstdc++ headers should have pop/push
 of the visibility around the declarations

pcarlini at suse dot de wrote:
> ------- Additional Comments From pcarlini at suse dot de  2005-05-17 19:05 -------
> 
>>This patch looks sensible to me, but it should be approved by a V3 
>>maintainer.
> 
> 
> Thanks a lot Mark, I'll try to get to it soon. But, the real reason we don't
> have those bits already is that there are outstanding front-end issues that
> apparently nobody cares about.

One of HJ's patches is a middle-end patch, and I'm not sure I know 
enough to review it.  I'd have to start by researching the ELF spec, for 
example, and we've found that various version of binutils have weird 
behavior around weak/linkonce.  So, I'm scared of that one.

The front end patch is OK.



-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-17 21:47 -------
Subject: Bug 19664

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	hjl@gcc.gnu.org	2005-05-17 21:47:13

Modified files:
	gcc/cp         : ChangeLog decl2.c 

Log message:
	2005-05-17  H.J. Lu  <hongjiu.lu@intel.com>
	
	PR C++/19664
	* decl2.c (determine_visibility): Don't set visibility to
	hidden if it has been set explicitly by user.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4745&r2=1.4746
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.781&r2=1.782



-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2005-05-17 21:50 -------
Mark, is

http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html

OK for mainline as well as 4.0?

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2005-05-17 21:58 -------
Subject: Re:  libstdc++ headers should have pop/push
 of the visibility around the declarations

hjl at lucon dot org wrote:
> ------- Additional Comments From hjl at lucon dot org  2005-05-17 21:50 -------
> Mark, is
> 
> http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html
> 
> OK for mainline as well as 4.0?

It's OK for mainline.  It's not OK for 4.0 unless it's a regression.



-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-05-17 22:00 -------
> One of HJ's patches is a middle-end patch, and I'm not sure I know 
> enough to review it.  I'd have to start by researching the ELF spec, for 
> example, and we've found that various version of binutils have weird 
> behavior around weak/linkonce.  So, I'm scared of that one.

I understand, of course. Maybe, with your release manager and global maintainer
hat, you can "officially" ask the intervention of a middle-end person? My point
was also this one...
 
> The front end patch is OK.

Thanks a lot. And, as soon as "pluto" has finished testing the whole package
I will personally take care of the v3 bits.

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pluto at agmk dot net]

------- Additional Comments From pluto at agmk dot net  2005-05-18 15:42 -------
(In reply to comment #50)  
  
> Thanks a lot. And, as soon as "pluto" has finished testing the whole package  
> I will personally take care of the v3 bits.  
  
on powerpc OpenEXR builds/links fine too. 
finally it works on amd64/powerpc/ia32 with -fvisibility-inlines-hidden. 
these 3 patches stay with me :) 
 

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-05-18 15:45 -------
Great! I forgot to thank you for all your testing efforts: thanks! I'm going to
have a final look and commit the v3 bits. Then, strong of your test, I'm also
going to ping again on gcc-patches the middle-end bits.

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[bernie at develer dot com]

------- Additional Comments From bernie at develer dot com  2005-05-19 10:00 -------
(In reply to comment #49)

> > Mark, is
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html
> > 
> > OK for mainline as well as 4.0?
> 
> It's OK for mainline.  It's not OK for 4.0 unless it's a regression.

It's not a regresion, but it causes KDE to miscompile
with GCC 4.0.0.  Could we apply it for 4.0 anyway?


-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2005-05-19 19:21 -------
Subject: Re:  libstdc++ headers should have pop/push
 of the visibility around the declarations

bernie at develer dot com wrote:

> It's not a regresion, but it causes KDE to miscompile
> with GCC 4.0.0.  Could we apply it for 4.0 anyway?

No; we confine ourselves to regressions.  If it wasn't a regression, 
there must be some workaround that KDE is using for previous releases 
that it can continue to use here.



-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[lanius at gentoo dot org]

------- Additional Comments From lanius at gentoo dot org  2005-05-20 08:35 -------
no workaround, the flag was just disabled on the affected architectures 

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pluto at agmk dot net]

------- Additional Comments From pluto at agmk dot net  2005-05-20 08:58 -------
(In reply to comment #54) 
> Subject: Re:  libstdc++ headers should have pop/push 
>  of the visibility around the declarations 
>  
> bernie at develer dot com wrote: 
>  
> > It's not a regresion, but it causes KDE to miscompile 
> > with GCC 4.0.0.  Could we apply it for 4.0 anyway? 
>  
> No; we confine ourselves to regressions.  If it wasn't a regression,  
> there must be some workaround that KDE is using for previous releases  
> that it can continue to use here. 
 
kde-core team already blacklisted gcc-4.0.0 due to detected bugs. 
they'll probably do the same thing with incoming 4.0.x releases 
due to gcc's rules which block major bugfixes != regression fixes. 
there is no logic reason for making workarounds for valid c++ code 
and releasing buggy 4.0.x branch. 

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pluto at agmk dot net]

------- Additional Comments From pluto at agmk dot net  2005-05-20 09:02 -------
(In reply to comment #52) 
> Great! I forgot to thank you for all your testing efforts: thanks! (...) 
 
i'll test these fixes on alpha/sparc{32,64} too in near feature. 
i have machines but no time :/ 
 

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-05-20 09:03 -------
FWIW, I agree, as far as the visibility issues are concerned (I don't want to
say something more general): the issues are *long* standing, important projects
are already using the features and nobody (almost ;) cares about the bugs in
the existing implementation. This is BAD. Either we fix those bugs ASAP,
everywhere the feature is present, or (we scrap away everything and/or advertise
the feature itself as broken).

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2005-05-20 18:48 -------
Subject: Re:  libstdc++ headers should have pop/push
 of the visibility around the declarations

lanius at gentoo dot org wrote:
> ------- Additional Comments From lanius at gentoo dot org  2005-05-20 08:35 -------
> no workaround, the flag was just disabled on the affected architectures 

Then, can it not be left disabled for 4.0.x as well?



-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[aj at suse dot de]

------- Additional Comments From aj at suse dot de  2005-05-21 16:50 -------
Subject: Re:  libstdc++ headers should have pop/push of the visibility around the declarations

"mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> writes:

> Then, can it not be left disabled for 4.0.x as well?

It could - but people do want to use it.  This is a rather important
improvement and people have been waiting for this feature to see it in
production since some time now.

Andreas


-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-07-06 10:40 -------
> should i update the mainline patch?

Well, thanks for the offer, but the real blocker is 20218, which cannot be
fixed yet, because, basically, *all* the back ends need tweaking:

   http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02226.html

Probably, I should find a way to more effectively ping the maintainers... 

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-14 16:59 -------
*** Bug 22482 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |caolanm at redhat dot com


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-21 16:17 -------
*** Bug 22587 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |debian-gcc at lists dot
                   |                            |debian dot org


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2005-08-21 20:25 -------
*** Bug 22185 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pedro dot lamarao at mndfck
                   |                            |dot org


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-29 20:57 -------
*** Bug 23628 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmarcus at emarcus dot org


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[geoffk at gcc dot gnu dot org]

------- Additional Comments From geoffk at gcc dot gnu dot org  2005-08-29 22:21 -------
There was a comment in here about making visibility control happen at the namespace level.

How would this work with, say, 'vector<mytype>'?  I would expect that if -fvisibility=hidden is set, then 
this instantiation should also be hidden, because presumably 'mytype' is a type private to this object.  If 
some other object defines a different 'mytype', it certainly shouldn't use the same 'vector' implementation.

-- 


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