[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

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

[funtoos at yahoo dot com]

------- Comment #108 from funtoos at yahoo dot com  2007-05-28 17:47 -------
but comments in bug 20218 say that its fixed in mainline, which means there was
a fix put into gcc for hidden visibility. So, are both the fix from prerelease
binutils and gcc mainline needed to fix this completely?


-- 


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

[simon dot strandman at telia dot com]

------- Comment #107 from simon dot strandman at telia dot com  2007-05-28 11:49 -------
(In reply to comment #106)
> I haven't tried the fix in 20218. surprisingly, moving to binutils
> 2.17.50.0.16.20070511 got rid of that problem. Do you know what exactly is
> going on? how did the latest binutils bypass the bug 20218?
> 

Probably because this bug is fixed in the prerelase binutils:
http://sourceware.org/bugzilla/show_bug.cgi?id=3666


-- 


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

[funtoos at yahoo dot com]

------- Comment #106 from funtoos at yahoo dot com  2007-05-28 05:16 -------
I haven't tried the fix in 20218. surprisingly, moving to binutils
2.17.50.0.16.20070511 got rid of that problem. Do you know what exactly is
going on? how did the latest binutils bypass the 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

[pluto at agmk dot net]

------- Comment #105 from pluto at agmk dot net  2007-05-28 05:01 -------
(In reply to comment #104)
> kdelibs doesn't link with gcc-4.2.0 with hidden visibility.

you need a path for pr20218.


-- 


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

[funtoos at yahoo dot com]

------- Comment #104 from funtoos at yahoo dot com  2007-05-28 04:15 -------
kdelibs doesn't link with gcc-4.2.0 with hidden visibility. It compiles and
links fine with gcc 4.1.2 with patch from Comment #86. That patch was included
by gentoo till 4.1.2 and dropped because this bug is supposedly fixed in 4.2.0.

I am having difficulty understanding it. How is it fixed if it doesn't even
match the functionality provided by one of the earlier proposed patches? Or Is
it that the kdelibs-3.5.[67] code needs to change for the new patch in GCC
4.2.0? Where is the problem?

The message from kdelibs link is:
--------------------------------------
/bin/sh ../libtool --silent --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ 
-Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align
-Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -O2
-march=k8 -msse2 -msse3 -fforce-addr -pipe -Wformat-security
-Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new
-fno-common -fvisibility=hidden -fvisibility-inlines-hidden 
-DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT
-DQT_NO_TRANSLATION   -Wl,-O1 -Wl,--enable-new-dtags -o libkhtml.la -rpath
/usr/kde/3.5/lib64 -version-info 6:0:2 -no-undefined -Wl,--no-undefined
-Wl,--allow-shlib-undefined -Wl,--version-script=./libkhtml.map
-L/usr/kde/3.5/lib64 -L/usr/qt/3/lib64 -L/usr/lib64    libkhtml_la.all_cc.lo
libkhtml_la.all_cpp.lo  ./xml/libkhtmlxml.la ./html/libkhtmlhtml.la
./rendering/libkhtmlrender.la ./css/libkhtmlcss.la ./misc/libkhtmlmisc.la
ecma/libkjs_html.la ./dom/libkhtmldom.la  ../kparts/libkparts.la 
../kdeprint/libkdeprint.la ../kutils/libkutils.la
../kwallet/client/libkwalletclient.la
/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.0/../../../../x86_64-pc-linux-gnu/bin/ld:
./html/.libs/libkhtmlhtml.a(libkhtmlhtml_la.all_cpp.o): relocation
R_X86_64_PC32 against `vtable for DOM::HTMLPreElementImpl' can not be used when
making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.0/../../../../x86_64-pc-linux-gnu/bin/ld:
final link failed: Bad value
collect2: ld returned 1 exit status
make[3]: *** [libkhtml.la] Error 1
make[3]: Leaving directory
`/home/tmp/portage/kde-base/kdelibs-3.5.7/work/kdelibs-3.5.7/khtml'
make[2]: *** [all-recursive] Error 1
----------------------------------------------------- 


-- 

funtoos at yahoo dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |funtoos at yahoo 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]

------- Comment #103 from pinskia at gcc dot gnu dot org  2007-04-03 17:37 -------
*** Bug 31459 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rjarrett at mathworks 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]

------- Comment #102 from pinskia at gcc dot gnu dot org  2007-02-22 23:58 -------
*** Bug 30900 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |centi_riccardo at libero dot
                   |                            |it


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]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.2.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

[bkoz at gcc dot gnu dot org]

------- Comment #101 from bkoz at gcc dot gnu dot org  2006-08-22 12:44 -------
Fixed.


-- 

bkoz at gcc dot gnu dot org changed:

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


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]

------- Comment #100 from bkoz at gcc dot gnu dot org  2006-07-28 04:57 -------
Subject: Bug 19664

Author: bkoz
Date: Fri Jul 28 04:57:34 2006
New Revision: 115790

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115790
Log:
2006-07-27  Benjamin Kosnik  <bkoz@wells.artheist.org>

        PR libstdc++/19664 round 3      
        * include/Makefile.am (tr1_headers): Add hashtable_policy.h.
        * include/Makefile.in: Regenerate.
        * include/tr1/hashtable: Move policy classes into...
        * include/tr1/hashtable_policy.h: ... this. New.

        * src/globals_locale.cc: Move contents....
        * src/locale_init.cc: ... to here, put in anonymous namespace.
        * src/Makefile.am: Remove globals_locale.cc.
        * src/Makefile.in: Regenerate.

        * src/locale.cc: Convert __gnu_internal to anonymous namespace.
        * src/debug.cc: Same.
        * src/ext-inst.cc: Same.
        * src/mt_allocator.cc: Same.
        * src/pool_allocator.cc: Same.

        * include/tr1/random: Convert std::tr1::_Private to anonymous
        namespace.
        * include/tr1/random.tcc: Same.

        * include/tr1/hashtable: Move ::Internal to std::tr1::detail and
        enclose bits that can actually be internal in in anonymous
        namespace.
        * include/tr1/unordered_set: Adjust explicit qualifications for
        namespace changes.
        * include/tr1/unordered_map: Same.

        * include/tr1/cmath: Convert __gnu_internal to nested detail namespace.

        * include/bits/cpp_type_traits.h: Move __type_type into anonymous
        namespace.

        * include/ext/rope: Change _Rope_constants to anonymous namespace.
        * include/ext/ropeimpl.h: Same.
        * src/ext-inst.cc: Same.


Added:
    trunk/libstdc++-v3/include/tr1/hashtable_policy.h
Removed:
    trunk/libstdc++-v3/src/globals_locale.cc
Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/Makefile.am
    trunk/libstdc++-v3/include/Makefile.in
    trunk/libstdc++-v3/include/bits/cpp_type_traits.h
    trunk/libstdc++-v3/include/ext/rope
    trunk/libstdc++-v3/include/ext/ropeimpl.h
    trunk/libstdc++-v3/include/tr1/cmath
    trunk/libstdc++-v3/include/tr1/hashtable
    trunk/libstdc++-v3/include/tr1/random
    trunk/libstdc++-v3/include/tr1/random.tcc
    trunk/libstdc++-v3/include/tr1/unordered_map
    trunk/libstdc++-v3/include/tr1/unordered_set
    trunk/libstdc++-v3/src/Makefile.am
    trunk/libstdc++-v3/src/Makefile.in
    trunk/libstdc++-v3/src/debug.cc
    trunk/libstdc++-v3/src/ext-inst.cc
    trunk/libstdc++-v3/src/locale.cc
    trunk/libstdc++-v3/src/locale_init.cc
    trunk/libstdc++-v3/src/mt_allocator.cc
    trunk/libstdc++-v3/src/pool_allocator.cc


-- 


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]

------- Comment #99 from bkoz at gcc dot gnu dot org  2006-07-20 23:37 -------
Subject: Bug 19664

Author: bkoz
Date: Thu Jul 20 23:37:27 2006
New Revision: 115632

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115632
Log:
2006-07-20  Benjamin Kosnik  <bkoz@redhat.com>
            Jakub Jelinek  <jakub@redhat.com>

        PR libstdc++/19664 round 1
        * acinclude.m4 (GLIBCXX_ENABLE_VISIBILITY): Check it.
        * configure.ac: Use it.
        * configure: Regenerate.
        * docs/html/configopts.html: Document it.
        * include/Makefile.am: Slip in to c++config.
        * include/Makefile.in: Regenerate.
        * include/bits/c++config (_GLIBCXX_VISIBILITY): New.
        (_GLIBCXX_BEGIN_NAMESPACE): Use it.
        (_GLIBCXX_END_NAMESPACE): Use it.
        (_GLIBCXX_BEGIN_NESTED_NAMESPACE): Use it.
        (_GLIBCXX_END_NESTED_NAMESPACE): Use it.                
        * src/debug.cc: Mark __gnu_internal namespace with hidden
        visibility attribute.
        * src/ext-inst.cc: Same.
        * src/globals_io.cc: Same.
        * src/globals_locale.cc: Same.
        * src/ios_init.cc: Same.
        * src/locale.cc: Same.
        * src/mt_allocator.cc: Same.
        * src/pool_allocator.cc: Same.


Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/Makefile.in
    trunk/libstdc++-v3/acinclude.m4
    trunk/libstdc++-v3/configure
    trunk/libstdc++-v3/configure.ac
    trunk/libstdc++-v3/docs/html/configopts.html
    trunk/libstdc++-v3/include/Makefile.am
    trunk/libstdc++-v3/include/Makefile.in
    trunk/libstdc++-v3/include/bits/c++config
    trunk/libstdc++-v3/libmath/Makefile.in
    trunk/libstdc++-v3/libsupc++/Makefile.in
    trunk/libstdc++-v3/po/Makefile.in
    trunk/libstdc++-v3/src/Makefile.in
    trunk/libstdc++-v3/src/debug.cc
    trunk/libstdc++-v3/src/ext-inst.cc
    trunk/libstdc++-v3/src/globals_io.cc
    trunk/libstdc++-v3/src/globals_locale.cc
    trunk/libstdc++-v3/src/ios_init.cc
    trunk/libstdc++-v3/src/locale.cc
    trunk/libstdc++-v3/src/locale_init.cc
    trunk/libstdc++-v3/src/mt_allocator.cc
    trunk/libstdc++-v3/src/pool_allocator.cc
    trunk/libstdc++-v3/testsuite/Makefile.in


-- 


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]

------- Comment #98 from pinskia at gcc dot gnu dot org  2006-07-20 22:01 -------
*** Bug 28449 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ph0enix at ngs dot ru


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]

------- Comment #97 from bkoz at gcc dot gnu dot org  2006-07-19 02:56 -------
Mine.


-- 

bkoz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2005-01-29 15:32:29         |2006-07-19 02:56:24
               date|                            |


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]

------- Comment #96 from bkoz at gcc dot gnu dot org  2006-07-19 02:52 -------
Created an attachment (id=11912)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11912&action=view)
viz patch part one


Hey Jakub.

Here's a way to start in on this.

This does two things:

1) adds default visibility attributes to 
namespace std
namespace std::tr1
namespace __gnu_cxx

2) adds hidden visibility attributes to
namespace __gnu_internal

There are a couple of things I want to do in addition to this, but these can be
added in later. (Such as move as much __gnu_internal into anonymous namespaces,
consolidate various internal namespaces into anonymous namespaces or
__gnu_internal, relocation tuning, consolidation of visibility schemes between
libsupc++ and libstdc++). 

Testing on so_7 with namespace associations is in progress.

tested x86/linux
tested x86/linux CXXFLAGS="-fvisibility=hidden" (fails)


-- 


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

[jakub at redhat dot com]

------- Comment #95 from jakub at redhat dot com  2006-07-15 10:34 -------
Can this be revisited now?
namespaces now can have the visibility attribute, although it has to be
present on each opening namespace.
Guess sticking __attribute__((__visibility__("default"))) into
_GLIBCXX_BEGIN_NAMESPACE and similar macros could do the trick.


-- 


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]

------- Comment #94 from pinskia at gcc dot gnu dot org  2006-04-26 02:13 -------
*** Bug 26846 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |laszlo dot szakony at
                   |                            |philips 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

[geoffk at geoffk dot org]

------- Comment #93 from geoffk at geoffk dot org  2006-04-04 00:23 -------
Subject: Re:  libstdc++ headers should have pop/push of the visibility around
the declarations


On 03/04/2006, at 4:57 PM, pinskia at gcc dot gnu dot org wrote:

> ------- Comment #92 from pinskia at gcc dot gnu dot org  2006-04-03  
> 23:57 -------
> Both PR 27000 and bug 26984 are reasons why push/pop will fail  
> currently.

It's probably OK if the visibility you're pushing is 'default'.  At  
least, it's no worse to push default than it would be to not push  
anything.


-- 


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]

------- Comment #92 from pinskia at gcc dot gnu dot org  2006-04-03 23:57 -------
Both PR 27000 and bug 26984 are reasons why push/pop will fail currently.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |26984


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

[mueller at gcc dot gnu dot org]

------- Comment #91 from mueller at gcc dot gnu dot org  2006-03-14 09:24 -------
well, of course, because your libstdc++ is compiled with the wrong (LSB
incompliant btw) stdc++ allocator. 


-- 


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]

------- Comment #90 from pluto at agmk dot net  2006-03-13 20:17 -------
with 4.1.1 snapshot + patches I get an arts crash today on my x86_64 box.

Starting program: /usr/bin/artsd
Program received signal SIGSEGV, Segmentation fault.
0x00002aaaaaf641d8 in __gnu_cxx::__mt_alloc<Arts::Notification*,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate () from
/usr/lib64/libartsflow.so.1
(gdb) bt
#0  0x00002aaaaaf641d8 in __gnu_cxx::__mt_alloc<Arts::Notification*,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate ()
    from /usr/lib64/libartsflow.so.1
#1  0x00002aaaaba4a908 in std::_Deque_base<Arts::Notification,
std::allocator<Arts::Notification> >::_M_initialize_map ()
    from /usr/lib64/libmcop.so.1
#2  0x00002aaaaba49145 in Arts::NotificationManager::NotificationManager ()
    from /usr/lib64/libmcop.so.1
#3  0x00002aaaaba2660a in Arts::Dispatcher::Dispatcher ()
    from /usr/lib64/libmcop.so.1
#4  0x000000000041c227 in main (argc=1, argv=0x7fffffe818f8) at artsd.cc:275

arts works fine with visibiliy feature disabled.

$ gcc -v
Reading specs from /usr/lib64/gcc/x86_64-pld-linux/4.1.1/specs
Target: x86_64-pld-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--libdir=/usr/lib64 --libexecdir=/usr/lib64 --infodir=/usr/share/info
--mandir=/usr/share/man --x-libraries=/usr/lib64 --enable-shared
--enable-threads=posix --enable-languages=c,c++,fortran,objc,obj-c++,ada,java
--enable-c99 --enable-long-long --enable-multilib --enable-nls --disable-werror
--with-gnu-as --with-gnu-ld --with-demangler-in-ld --with-system-zlib
--with-slibdir=/lib64 --without-system-libunwind --enable-cmath
--with-long-double-128 --with-gxx-include-dir=/usr/include/c++/4.1.1
--disable-libstdcxx-pch --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--with-qt4dir=/usr/lib64/qt4 --disable-libjava-multilib --enable-libgcj
--enable-libgcj-multifile --enable-libgcj-database --enable-gtk-cairo
--enable-java-awt=qt,gtk,xlib --enable-jni --enable-xmlj --enable-alsa
--enable-dssi x86_64-pld-linux
Thread model: posix
gcc version 4.1.1 20060308 (prerelease) (PLD-Linux)


-- 


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]

------- Comment #89 from pinskia at gcc dot gnu dot org  2006-02-11 17:14 -------
*** Bug 26217 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gcc at dave dot dribin 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]

------- Comment #88 from geoffk at gcc dot gnu dot org  2005-12-15 23:41 -------
This patch doesn't solve the vector<mytype> issue, does it?  It doesn't look
like it, I would have expected it to need some C++ frontend changes.


-- 


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]

------- Comment #87 from pluto at agmk dot net  2005-12-06 17:05 -------
current 4.1(+libstdc++ patch) works fine for PR21382 on amd64 and ppc.


-- 


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

[bero at arklinux dot org]

------- Comment #86 from bero at arklinux dot org  2005-11-03 09:38 -------
Created an attachment (id=10120)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10120&action=view)
Updated version of the patch to apply on current SVN


-- 


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 geoffk dot org]

------- Comment #84 from geoffk at geoffk dot org  2005-11-01 04:30 -------
Subject: Re:  libstdc++ headers should have pop/push of the visibility around
the declarations


On 31/10/2005, at 7:59 PM, bkoz at gcc dot gnu dot org wrote:


> Geoff, it's not as simple as just marking throwable types, all  
> typeinfo, etc.
> I'm performing an audit, but it's stuff like local statics as well.
>

Right, I wasn't trying to say that just marking the throwable types  
would be a complete solution (for anyone), just that it was easy,  
clearly correct as far as it went, and it would reduce the problem.


> This has to be done very carefully for a C++ library, which isn't  
> as clearly defined as C libraries that are already using this  
> feature (but that don't have to deal with vague linkage.)
>

Plus, we don't really know what it should mean yet.  For instance, if  
everything is compiled with visibility hidden, and dylib A throws  
"vector<int>", should that be catchable in dylib B?  I can think of  
good arguments for "yes", "no", and "undefined", which I guess means  
that "undefined" should win.


------- Comment #85 from geoffk at geoffk dot org  2005-11-01 04:30 -------
Created an attachment (id=10094)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10094&action=view)


-- 


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]

------- Comment #83 from bkoz at gcc dot gnu dot org  2005-11-01 03:59 -------

I agree Geoff, we should hold off on this for 4.1, and try to hit 4.2. If
things get solid sooner, maybe this can be reconsidered. Adding this patch to
4.0.x is out of the question, it has the potential to change too many things.

I am working on this general issue at the moment. So, I will reassign to me
since Paolo suggested it.

Geoff, it's not as simple as just marking throwable types, all typeinfo, etc.
I'm performing an audit, but it's stuff like local statics as well. This has to
be done very carefully for a C++ library, which isn't as clearly defined as C
libraries that are already using this feature (but that don't have to deal with
vague linkage.)

I'll come up with a gcc bugzilla enhancement request for visibility attributes
on namespaces this week.


-- 


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]

------- Comment #82 from pcarlini at suse dot de  2005-11-01 02:21 -------
To clarify: I have unassigned myself from this bug because I don't consider
myself sufficiently competent in this area to evaluate all the possible trade-
offs of the issue and don't want to block in any way the work of knowledgeable
people, Geoff, for instance. Help is much appreciated. Thanks.


-- 


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]

-- 

pcarlini at suse dot de changed:

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


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 geoffk dot org]

------- Comment #81 from geoffk at geoffk dot org  2005-10-31 23:29 -------
Subject: Re:  libstdc++ headers should have pop/push of the visibility around
the declarations


On 31/10/2005, at 2:45 PM, mueller at kde dot org wrote:


> ------- Comment #80 from mueller at kde dot org  2005-10-31 22:45  
> -------
> - not hiding a symbols is better than the resulting issues when  
> hiding a symbol
>  which should be exported. for example right now the function  
> static pointer
>  pointing to libstdc++'s memory allocator is hidden, which causes  
> STL usages
>  to just randomly crash when used across linking boundaries.  
> crashing is worse
>  than the performance penality by exported symbols
>

I wasn't thinking so much of the performance penalty, but rather of  
the ABI impact.  Suddenly, your dynamic library, which you thought  
had carefully controlled exports (maybe it shouldn't export any C++  
interfaces of its own at all), is exporting a global C++ type,  
'std::vector<mytype>', which could conflict with any similarly-named- 
but-different type anywhere in a program that uses the library.

Performance is also a concern, of course.


> - of course just exporting those classes that *should* be exported  
> would be
>  much more clever. I just thought if its so difficult to get a  
> brain-dead
> simple patch that makes everything work not getting applied within  
> 6 months
>  then the stripped-down just-exporting-what-is-really needed (which  
> requires
>   a lot of in-depth knowledge and a lot of testing) would need more  
> something
>  like 6 years to get applied.
>
> Anyway, I volunteer to help reducing the amount of exported classes  
> if thats
> what makes you apply the patch. The current brute-force export-all  
> patch
> fixes everything and is dead simple compared to such a "only export  
> what
> is needed  patch".
>

Well (after re-reading what the bug was originally about):

- You'll notice that the bug is about things which are not defined in  
this library, which can't possibly include the things I'm concerned  
about above, since every part of std::vector<mytype> must be defined  
in this library since nothing else knows about 'mytype'.  So it's  
certainly possible to fix it.

- But, I'm not sure that the front-end supports everything you'll  
need to mark all the right pieces.  For instance, ctype<mytype> has  
to be hidden, but ctype<char> has to be not hidden.  It would  
probably be easier to teach the front-end that "if I'm instantiating  
something, the resulting thing must have the most restrictive  
visibility of any of its parameters" than it would be to go around  
trying to put attributes on each little method.

- If that's too hard to do in time for 4.1, we could at least fix the  
related problems for non-x86-64 systems, which have to do with the  
classes thrown as exceptions; it's not useful to compile them with  
hidden visibility, since they're passed between libraries.  (They're  
mostly in libsupc++.)


-- 


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

[mueller at kde dot org]

------- Comment #80 from mueller at kde dot org  2005-10-31 22:45 -------
- if its not safe for all architectures we'd already run into heaps of problems
because both libsupc++ and libgcc2 already include similiar pragmas. 

- not hiding a symbols is better than the resulting issues when hiding a symbol
 which should be exported. for example right now the function static pointer
 pointing to libstdc++'s memory allocator is hidden, which causes STL usages
 to just randomly crash when used across linking boundaries. crashing is worse
 than the performance penality by exported symbols

- of course just exporting those classes that *should* be exported would be
 much more clever. I just thought if its so difficult to get a brain-dead
simple patch that makes everything work not getting applied within 6 months
 then the stripped-down just-exporting-what-is-really needed (which requires
  a lot of in-depth knowledge and a lot of testing) would need more something
 like 6 years to get applied. 

Anyway, I volunteer to help reducing the amount of exported classes if thats
what makes you apply the patch. The current brute-force export-all patch
fixes everything and is dead simple compared to such a "only export what
is needed  patch". 


-- 


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 geoffk dot org]

------- Comment #79 from geoffk at geoffk dot org  2005-10-31 22:14 -------
Subject: Re:  libstdc++ headers should have pop/push of the visibility around
the declarations


On 31/10/2005, at 10:37 AM, ismail at uludag dot org dot tr wrote:


> ------- Comment #78 from ismail at uludag dot org dot tr   
> 2005-10-31 18:37 -------
> Paolo, this is surely a bug fix. Why can't it make it to 4.1 ?  
> Waiting for 4.2
> means that unpatched gcc's will suffer for more.
>

I don't think the problem is solved yet, is it?  In addition to the  
question of whether the patch is actually safe for all architectures,  
there's also still the question of using standard library templates,  
like 'vector', on hidden types; this works now if you use - 
fvisibility=hidden, and it'd stop working if the patch was applied,  
so you'd just be trading one problem for another.  Better I think to  
not make this change in 4.1, at least that can't introduce any  
regressions, and work on the problem for 4.2.

However, maybe the problem would be much reduced if we marked some  
specific classes as not hidden: those which are thrown as  
exceptions.  There are only a handful of them, so we could do that  
with just an attribute, and surely that would be safe.  What do  
people think of that?


-- 


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

[ismail at uludag dot org dot tr]

------- Comment #78 from ismail at uludag dot org dot tr  2005-10-31 18:37 -------
Paolo, this is surely a bug fix. Why can't it make it to 4.1 ? Waiting for 4.2
means that unpatched gcc's will suffer for more.


-- 


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]

------- Comment #77 from pcarlini at suse dot de  2005-10-31 16:59 -------
Thanks Benjamin! Indeed, if you want to take care of this entire issue, you
are welcome (just reassign)! In any case, I'm not sure whether it's suited
for 4.1, at this point...


-- 


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]

------- Comment #76 from bkoz at gcc dot gnu dot org  2005-10-31 16:47 -------
Created an attachment (id=10085)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10085&action=view)
hidden visibility for __gnu_internal


Without per-namespace visibility attributes, this is what we will have to do
for the known internal parts of 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]

------- Comment #75 from pcarlini at suse dot de  2005-10-25 15:44 -------
(In reply to comment #74)
> furthermore I manually added push/pop macros to libstdc++ headers on a debian
> system (which is broken regarding visibility support) and it made my testcase
> pass. 

To be clear: I have nothing against adding those push/pop missing the
middle-end
fixes. But I want to be 100% sure that nothing breaks. Thus my plan: I will
update the patch doing that for mainline and ask Roger (the most qualified
person, apparently) before committing.


-- 


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

[mueller at kde dot org]

------- Comment #74 from mueller at kde dot org  2005-10-25 15:41 -------
yes, well one reason for it is that several libs (e.g. libgcc2) already use
push/pop visibility macros and it doesn't seem to harm. 

furthermore I manually added push/pop macros to libstdc++ headers on a debian
system (which is broken regarding visibility support) and it made my testcase
pass. 


-- 


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]

------- Comment #73 from pcarlini at suse dot de  2005-10-24 09:14 -------
(In reply to comment #72)
> why is it pointless? just because it doesn't work on some target architectures
> doesn't mean it doesn't work on most main archs. 

Are you really, really, sure that without patching the middle-end at all, only
changing the libstdc++-v3 headers benefits some targets without any side
effects? I'm not at all, given this tangle. Really, we want someone to work
seriously on
the various serious outstanding bugs of the machinery, please if you consider
it useful in principle for your project ask the maintainers and the
knowledgeable
compiler people to work on it, I tried, but I failed, by and large.


-- 


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

[mueller at kde dot org]

------- Comment #72 from mueller at kde dot org  2005-10-24 05:22 -------
why is it pointless? just because it doesn't work on some target architectures
doesn't mean it doesn't work on most main archs. 

I find it pointless that a patch isn't applied just because it doesn't work on
some archs (while it doesn't additionally break anything on those archs because
all *this* patch does is to *ensure* that hidden visibility is disabled)


-- 

mueller at kde dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mueller at kde 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

[pcarlini at suse dot de]

------- Comment #71 from pcarlini at suse dot de  2005-10-21 11:40 -------
(In reply to comment #70)
> whats the status of the patch? can we at least have the visibility push/pop
> patch for libstdc++ in gcc 4.0.x branch?

See comment #63: at this stage changing libstdc++ is pointless.


-- 


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

[mueller at kde dot org]

------- Comment #70 from mueller at kde dot org  2005-10-21 11:36 -------
whats the status of the patch? can we at least have the visibility push/pop
patch for libstdc++ in gcc 4.0.x branch?

Marc: what is the reason this patch is rejected? sure its not a regression, but
visibility support is entirely useless without visibility support in libstdc++.
The push/pop part is not the ideal solution (as it basically disables
visibility for libstdc++), but its a can't-break workaround for a very pressing
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

[pinskia at gcc dot gnu dot org]

------- Comment #69 from pinskia at gcc dot gnu dot org  2005-10-08 13:42 -------
*** Bug 24272 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lothar at tradescape dot biz


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