https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107128
--- Comment #7 from Mike Hommey ---
Forget my last comment, it came from the use of a sysroot with an older glibc.
I wonder why the sysroot path didn't appear in those messages...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107128
Mike Hommey changed:
What|Removed |Added
CC||mh+gcc at glandium dot org
--- Comment
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
Target Milestone: ---
Reproducer:
```
#include
class nsISupports {
public:
virtual int Release();
};
struct JSPrincipals {
std::atomic refcount;
};
class nsJSPrincipals : nsISupports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106633
Mike Hommey changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
Target Milestone: ---
This was not happening before GCC 12.
Reduced testcase from a Firefox build failure we got in Debian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104142
--- Comment #7 from Mike Hommey ---
(In reply to Mike Hommey from comment #6)
> There's a different warning that interestingly only happens on 11.2 and 11.3
> (not 11.1 or earlier versions), that is fixed by the patch in this bug:
Forgot to men
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104142
Mike Hommey changed:
What|Removed |Added
CC||mh+gcc at glandium dot org
--- Comment
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
Target Milestone: ---
(Note I'm not entirely sure this is a GCC bug, but it doesn't happen with GCC <
11 and with clang)
Reduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785
--- Comment #7 from Mike Hommey ---
It's worth noting that the clang variant of the code makes use of
__builtin_shufflevector, which the gcc variant doesn't (per
https://searchfox.org/mozilla-central/source/gfx/wr/swgl/src/vector_type.h), so
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785
--- Comment #6 from Mike Hommey ---
Replacing __attribute__((always_inline)) with inline on the two blend_pixels
functions makes it go down to 30s with GCC 10.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1700520#c9 why the functions
were ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785
--- Comment #4 from Mike Hommey ---
GCC 11 is the package in Debian experimental, so however it's built.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
Target Milestone: ---
Created attachment 50475
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50475&action=edit
gl.ii.gz
Compiling the attached preprocessed source takes 27 minut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99784
--- Comment #3 from Mike Hommey ---
PR 96956 only really talks about this: "You may not use this mechanism to jump
to code in a different function. If you do that, totally unpredictable things
happen.".
My testcase doesn't involve jumping to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99784
--- Comment #1 from Mike Hommey ---
This is reproducible with all versions of GCC on godbolt, including trunk.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
Target Milestone: ---
Reduced testcase:
```
extern void bar();
extern void qux(void*);
void foo() {
bar();
here:
qux(&&here);
}
```
Resulting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756
--- Comment #22 from Mike Hommey ---
For the record, this also affects ppc64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756
--- Comment #20 from Mike Hommey ---
Note this also affects mips and presumably mips64 (except for the latter, the
code has a ifdef that disables inlining presumably because of this ICE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756
--- Comment #19 from Mike Hommey ---
Applying the patch from PR90139 and this one works fixes the ICEs on this file
with both GCC 7 and 8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756
--- Comment #18 from Mike Hommey ---
And similar ICE as comment 14 with 8.3 too.
9.1 works with the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756
--- Comment #17 from Mike Hommey ---
(In reply to Mike Hommey from comment #16)
> Similar ICE with 7.3.
And 7.4 (and to be clear, this is similar ICE as comment 14)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756
--- Comment #16 from Mike Hommey ---
Similar ICE with 7.3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756
--- Comment #14 from Mike Hommey ---
If I apply the patch on 6.4, I'm getting a different ICE:
internal compiler error: in emit_block_move_hints, at expr.c:1099
[task 2019-07-04T09:48:09.107Z] 09:48:09 INFO - static void
exec_ops(const Op*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756
--- Comment #4 from Mike Hommey ---
Also note it does *not* happen on i686 when SSE is enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756
Mike Hommey changed:
What|Removed |Added
CC||mh+gcc at glandium dot org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
--- Comment #14 from Mike Hommey ---
(In reply to Andreas Schwab from comment #13)
> alignof(long long) "type of a complete object"
> alignof(foo) "type of a subobject"
But that doesn't tell why the alignment of a long long is 8 as a complete
ob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
Mike Hommey changed:
What|Removed |Added
CC||mh+gcc at glandium dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70559
--- Comment #2 from Mike Hommey ---
Created attachment 38198
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38198&action=edit
nsTextFormatter.ii
Err, sorry.
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
Target Milestone: ---
We've recently switched to GCC 4.8 to build Firefox (yeah, I know...), and
valgrind detected an error th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65765
--- Comment #5 from Mike Hommey ---
I can confirm that building Firefox with -fno-ipa-icf "fixes" the issue as well
(that is, that the testcase is correctly related to the Firefox breakage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65765
--- Comment #1 from Mike Hommey ---
git bisect identified this commit as the first one where the reduced testcase
fails:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=52200d03c231f0bddbd4bbc5cd3608c6a1dd4598
svn+ssh://gcc.gnu.org/svn/gcc/trunk@2
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
Created attachment 35314
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35314&action=edit
reduced.tgz
When building Firefox with GCC 5 [1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65761
--- Comment #6 from Mike Hommey ---
It also doesn't happen at -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65761
--- Comment #5 from Mike Hommey ---
I can reproduce with:
g++ -m32 -march=pentiumpro -o Unified_cpp_js_src5.o -c -fPIC
-Wno-invalid-offsetof -fno-exceptions -std=gnu++0x -fprofile-use
-fprofile-correction -O3 -fno-omit-frame-pointer Unified_cpp_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65761
--- Comment #4 from Mike Hommey ---
Created attachment 35310
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35310&action=edit
Unified_cpp_js_src5.gcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65761
--- Comment #3 from Mike Hommey ---
Created attachment 35309
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35309&action=edit
Unified_cpp_js_src5.i
The full compile command line is:
g++ -m32 -march=pentiumpro -o Unified_cpp_js_src5.o -c
-
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
This happened while building Firefox with PGO with GCC 5.1.0-RC-20150412,
compiled with "--enable-languages=c,c++ --disable-nls
--disable-gnu-unique-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208
--- Comment #2 from Mike Hommey ---
This doesn't happen with gcc 4.9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208
--- Comment #1 from Mike Hommey ---
Created attachment 32812
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32812&action=edit
Corresponding assembly (compressed)
This is the assembly I got with the full normal command line. But I can
repro
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
Created attachment 32811
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32811&action=edit
Preprocessed source (compr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55650
--- Comment #4 from Mike Hommey ---
*** Bug 59973 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59973
Mike Hommey changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59973
--- Comment #1 from Mike Hommey ---
Created attachment 31971
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31971&action=edit
Value.ii.gz
Looks like the attachment didn't work at bug creation time.
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
$ g++-4.7 -o - -S Value.ii -std=gnu++0x -O1 -fprofile-generate
(snip)
.quad.LPBX1
.local.LPBX1
.comm.LPBX1,34359738368,64
$ g++-4.7 -o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56698
--- Comment #5 from Mike Hommey 2013-04-09
14:54:51 UTC ---
As noted in https://bugzilla.mozilla.org/show_bug.cgi?id=854105#c4, fileIndex
is uint32_t, so 0 - 1 is UINT32_MAX, which makes the error valid. Now the
question is why does it onl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56698
--- Comment #4 from Mike Hommey 2013-04-03
18:35:14 UTC ---
Created attachment 29800
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29800
nsDiskCacheMap.gcda
I can reproduce with the preprocessed file and this gcda with gcc 4.7.2-5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56698
--- Comment #3 from Mike Hommey 2013-04-03
15:46:04 UTC ---
Created attachment 29798
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29798
Preprocessed file
This is the preprocessed file.
In case that helps, the gcc it failed to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56698
--- Comment #1 from Mike Hommey 2013-03-23
18:11:16 UTC ---
Interestingly, if I modify CalculateFileIndex to return 3 instead of 0, the
error doesn't happen. So it might be a case of confusing gcc warning/error
message.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56698
Bug #: 56698
Summary: "array subscript is above array bounds" triggered on
code that doesn't have that problem
Classification: Unclassified
Product: gcc
Version: 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308
Mike Hommey changed:
What|Removed |Added
CC||mh+gcc at glandium dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56561
Mike Hommey changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56561
Bug #: 56561
Summary: Miscompilation with -Os -arm
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53829
Bug #: 53829
Summary: Trivial static initializers are created for
initialization with result of trivial static inline
functions
Classification: Unclassified
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53341
Bug #: 53341
Summary: overloaded operator delete(void *) appear in object
file even when not directly used
Classification: Unclassified
Product: gcc
Version: 4.7.0
St
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #127 from Mike Hommey 2012-05-11
08:52:24 UTC ---
(In reply to comment #126)
> (In reply to comment #124)
> > > Just for comparison, clang with -O4 runs only single threaded and does
> > > everything in memory (no streaming out). It u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50442
Mike Hommey changed:
What|Removed |Added
CC||mh+gcc at glandium dot org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49930
--- Comment #4 from Mike Hommey 2011-09-07
08:54:11 UTC ---
(In reply to comment #3)
> So just the getpagesize remains?
getpagesize is in libiberty, it shouldn't matter anymore
(In reply to comment #2)
> Note that sincos() was introduced with A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50022
--- Comment #1 from Mike Hommey 2011-08-08
10:44:27 UTC ---
Created attachment 24949
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24949
nsCookieService.i.xz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50022
Summary: [4.7 regression] "incorrect condition in IT block"
when building mozilla code base for ARM
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41159
Mike Hommey changed:
What|Removed |Added
CC||mh+gcc at glandium dot org
--- Comment #12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49930
Summary: Need some adjustments for bionic
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #101 from Mike Hommey 2011-06-15
11:38:01 UTC ---
(In reply to comment #100)
> Please note that this error only happens during a profiled build.
> Normal build seems to be OK.
FWIW: https://bugzilla.mozilla.org/show_bug.cgi?id=664387
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #84 from Mike Hommey 2011-04-12
10:53:44 UTC ---
(In reply to comment #83)
> > I am not sure if this is GCC bug or elfhack, but I would guess for
> elfhack actually.
>
> I guess you're right, because when I move the swap definitions:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #78 from Mike Hommey 2011-04-08
15:57:14 UTC ---
(In reply to comment #75)
> (In reply to comment #74)
> > Interesting. -O3 makes no difference for me. I will look into your dumps
> > if I
> > can spot something useful.
> > ...
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #45 from Mike Hommey 2011-02-12
09:32:34 UTC ---
Can you try mozilla-central revision 19f13dea4d4a?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #44 from Mike Hommey 2011-02-10
17:43:04 UTC ---
(In reply to comment #43)
> Ah, so this is a crash of the test, not of elfhack. Could you attach both
> test.so and test.so.bak files ?
Actually, it would be better to just do that on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #43 from Mike Hommey 2011-02-10
17:41:53 UTC ---
(In reply to comment #42)
> (In reply to comment #41)
> >
> > Segfaults or aborts ?
>
> Segfaults:
>
> ===
> === If you get failures below, please file a bug describing the error
> =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #41 from Mike Hommey 2011-02-09
14:34:08 UTC ---
(In reply to comment #40)
> I have just checked-out mozilla-central entirely by doing
>
> hg clone http://hg.mozilla.org/mozilla-central/
>
> and the elfhack test still segfaults for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #39 from Mike Hommey 2011-02-07
18:40:22 UTC ---
(In reply to comment #38)
> Created attachment 23253 [details]
> failing testcase
>
> With current mainline and top of tree mozilla, things seems to go well, sqlite
> issues are gone.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #9 from Mike Hommey 2010-12-11
14:36:36 UTC ---
(In reply to comment #7)
> Hi,
> thanks for testcase. What I was concerned about is the static linking case.
> When you have static library with constructors and main program with
> con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #1 from Mike Hommey 2010-12-02
19:24:44 UTC ---
Using .init_array/.fini_array instead of .ctors/.dtors removes the need for the
associated (relative) relocations, and avoids the backwards disk seeks on
startup (since while .ctors are
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
Summary: Replace .ctors/.dtors with .init_array/.fini_array on
targets supporting them
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority:
--- Comment #10 from mh+gcc at glandium dot org 2010-09-16 07:43 ---
(In reply to comment #9)
> Created an attachment (id=21806)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21806&action=view) [edit]
> testcase
>
> Here you go. This passes at -O0 but fails at
--- Comment #7 from mh+gcc at glandium dot org 2010-09-15 18:13 ---
Nice catch. BTW I read recently that gcc 4.5 assumes 16 bytes stack alignment,
is that x86 only or does that apply to x86-64 too ? (in which case we'd need to
be careful about that as well)
--
http://gcc.gn
--- Comment #25 from mh+gcc at glandium dot org 2010-09-15 14:01 ---
Oh, I was trying with -O2, yes, it works with -O1 -fno-tree-pta. Let me try on
the original code, too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
--- Comment #22 from mh+gcc at glandium dot org 2010-09-15 13:52 ---
(In reply to comment #21)
> For the original code? Then your reduced testcase is different from the
> original problem.
It doesn't work for the reduced testcase here, with gcc 4.5.1
--
http://
--- Comment #20 from mh+gcc at glandium dot org 2010-09-15 13:41 ---
(In reply to comment #19)
> Another workaround is to use -fno-tree-pta.
Doesn't work here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
--- Comment #18 from mh+gcc at glandium dot org 2010-09-15 13:14 ---
(In reply to comment #17)
> Thus, as a workaround you should make sure the asBits field matches
> pointer-size (so for example use uintptr_t isntead of uint64_t).
which is not possible in the original code,
--- Comment #16 from mh+gcc at glandium dot org 2010-09-15 12:52 ---
The real code where this gets problematic:
http://mxr.mozilla.org/mozilla-central/source/js/src/ctypes/CTypes.cpp#5615
The function it calls:
http://mxr.mozilla.org/mozilla-central/source/js/src/ctypes/CTypes.cpp#5542
--- Comment #15 from mh+gcc at glandium dot org 2010-09-15 12:47 ---
Note that the original code doesn't use char *. I used char * to make it easily
visible with a printf. Actually, just writing
void foo(jsval_layout l, void *s2) {
jsval_layout m;
m.asBits = l.asBits;
--- Comment #1 from mh+gcc at glandium dot org 2010-09-15 12:21 ---
Created an attachment (id=21800)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21800&action=view)
Fix stack allocation for ffi function calls on x86-64
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45677
: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libffi
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mh+gcc at glandium dot org
GCC target triplet: x86_64-*-linux
http://gcc.gn
--- Comment #12 from mh+gcc at glandium dot org 2010-09-15 12:11 ---
FWIW, it's still broken on a gcc trunk snapshot from the 28th of august.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
--- Comment #11 from mh+gcc at glandium dot org 2010-09-15 12:05 ---
Created an attachment (id=21799)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21799&action=view)
Reduced testcase
Inlining JSVAL_TO_PRIVATE by hand still makes it break, and reduces the
testcase
--- Comment #10 from mh+gcc at glandium dot org 2010-09-15 11:53 ---
Please note this actually only happens on x86. (I would change the summary and
target if I could)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
--- Comment #9 from mh+gcc at glandium dot org 2010-09-15 11:45 ---
Created an attachment (id=21798)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21798&action=view)
Reduced testcase
Both issues Taras mentioned are actually separated. One is an actual bug in ffi
(to b
--- Comment #6 from mh+gcc at glandium dot org 2010-03-02 17:56 ---
(In reply to comment #5)
> (In reply to comment #4)
> > So, in case I build with -g, I can just use -fno-asynchronous-unwind-tables
> > safely ?
>
> Yes it is safe but not recommended though.
--- Comment #4 from mh+gcc at glandium dot org 2010-03-02 17:48 ---
> Because it can be used for the backtrace when debugging. Without a frame
> pointer on x86/x86_64, you cannot get a real backtrace without unwinding info.
So, in case I build with -g, I can just use -fno-asynch
--- Comment #2 from mh+gcc at glandium dot org 2010-03-02 17:37 ---
(In reply to comment #1)
> That's because x86-64 defaults to -fasynchronous-unwind-tables. You really
> want that by default on x86_64, as frame pointer is usually omitted.
Why would you want -fasynchro
4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mh+gcc at glandium dot org
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet:
--- Comment #2 from mh+gcc at glandium dot org 2008-05-11 09:18 ---
Usually, when you're using visibility hidden, that means you want to avoid
exporting a lot of cruft symbols from a shared library... that the std::
namespace is always visibility default is an annoyance. Espec
.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mh+gcc at glandium dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36022
91 matches
Mail list logo
