https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56109
Paul Pluzhnikov changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83029
--- Comment #5 from Paul Pluzhnikov ---
(In reply to Jonathan Wakely from comment #4)
> Which version of glibc are you using?
"Debian GLIBC 2.24-12".
I believe this bug should be closed as fixed or invalid:
1. The original test case does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83029
--- Comment #3 from Paul Pluzhnikov ---
Reconfirmed with today trunk (r270470).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83029
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79111
Paul Pluzhnikov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189
--- Comment #9 from Paul Pluzhnikov ---
Thanks, H.J.
https://sourceware.org/bugzilla/show_bug.cgi?id=5784 has a few references, and
in particular https://sourceware.org/ml/libc-alpha/2012-09/msg00192.html is
important to consider.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189
--- Comment #6 from Paul Pluzhnikov ---
(In reply to Jakub Jelinek from comment #5)
> Because it is very expensive.
One impractical solution is to require '-pthread' on the compile and link line,
and link a libgcc_mt that has non-weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189
--- Comment #4 from Paul Pluzhnikov ---
(In reply to Jakub Jelinek from comment #3)
> This is a glibc bug
I (obviously) disagree.
, coming up with a set of weakref checks for gthr.h that
> would satisfy static linking of glibc and all possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189
--- Comment #1 from Paul Pluzhnikov ---
Crash stack for reference:
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x00477f7c in __gthread_mutex_lock
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Target Milestone: ---
Redirected here from GLIBC bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=21777
A trivial program
Priority: P3
Component: demangler
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Target Milestone: ---
Test case from LLVM libFuzzer.
Using current trunk binutils (libiberty identical to current trunk GCC
r244514):
cxxfilt
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Target Milestone: ---
Discovered with LLVM libFuzzer (http://llvm.org/docs/LibFuzzer.html).
Using current binutils trunk (libiberty is identical to r244484):
valgrind --leak-check=full build/binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
--- Comment #9 from Paul Pluzhnikov ---
Still broken on trunk @r231541. Closing on 2 years now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
--- Comment #11 from Paul Pluzhnikov ---
(In reply to Markus Trippelsdorf from comment #10)
> Patches are welcome.
Yes, I know. As I lamented in comment #7,
I don't know enough GCC internals to take this on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67396
--- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Andrew Pinski from comment #2)
Can you provide -ftime-report ?
Sure:
perl gen_bz18872.pl 2000 t.c gcc-svn-r227321/bin/gcc -c -O2 t.c
-ftime-report
Execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67396
--- Comment #5 from Paul Pluzhnikov ppluzhnikov at google dot com ---
please do before you report compile time regressions.
Ok. Here are the new numbers from current trunk built with
--enable-checking=release
(nothing's changed that I can see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67396
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC||jh
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Target Milestone: ---
Created attachment 36270
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36270action=edit
test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61022
--- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Still fails with trunk @r222386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
--- Comment #7 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Still broken on trunk @r221169.
Leaving known ICEs for = 1 year untouched seems... suboptimal.
(Sorry I don't know enough GCC internals to take this on.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65263
--- Comment #10 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Jan Hubicka from comment #9)
Paul, I fixed similar bug yesterday, so please check if it works now
I just built at current SVN trunk (r221126).
Filed PR 65287
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65263
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Created attachment 34927
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34927action=edit
test case
Continued from PR 65263
r221040 is also possibly causing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65287
--- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Created attachment 34928
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34928action=edit
c-reduce'd test case
A much shorter test:
const int __new_sys_siglist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978
--- Comment #9 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Jason Merrill from comment #8)
You shouldn't get the warning about IPPROTO_ICMP vs IPPROTO_ICMPV66, as they
are members of the same anonymous enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978
--- Comment #11 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Jason Merrill from comment #10)
Interesting, in glibc 2.18 (at least in glibc-headers-2.18-16.fc20.x86_64)
they are in the same enum.
The in.h is actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61022
--- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Still fails with trunk @r216948
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/18024040
Test:
int *b;
auto __attribute__ ((may_alias)) a = b; // replace auto with int* to fix
Using trunk @r216408:
r216408/bin/g++ -c -std=c++11 t.ii
t.ii:2:34: internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63540
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63149
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62310
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/16582830
Gcc 4.8, 4.9 and current trunk @r213084 are affected.
// --- cut ---
struct function
{
template typename _Functor function (_Functor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44122
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
--- Comment #6 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Still broken @r212875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59815
--- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Still broken @r212875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59812
--- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Reconfirmed @r212875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61833
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Created attachment 33134
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33134action=edit
test case
Google ref: b/16030670
Originally reported against gcc-4.8.
Attached test case causes gcc-4_9-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723
--- Comment #8 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Filed PR61833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723
--- Comment #5 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Paolo Carlini from comment #1)
I find this testcase rather weird
It's the result of creduce over a preprocessed original.
std::initializer_list isn't a random
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723
--- Comment #6 from Paul Pluzhnikov ppluzhnikov at google dot com ---
It turns out that the original unreduced test case does not error on trunk
@r212277;
it only ICEs on gcc-4.8 and gcc-4.9 branches.
But once I creduced it using 4.9
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/16030670.
AFAICT, this is broken in all of 4.7 / 4.8 / 4.9 / 4.10.
Accepted by Clang without warnings.
gcc-svn-r212277/bin/g++ -c -std=c++11 t.cc
t.cc: In function ‘void fn1()’:
t.cc:29:14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58930
--- Comment #5 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Paolo Carlini from comment #4)
Fixed for 4.10.0.
Can this be back-ported to gcc-4_9-branch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
--- Comment #5 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Still broken on trunk @r211990.
Any chance someone can look at this?
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/15883782
This broke on trunk sometime after r200178, is broken currently (r211990), and
also on gcc-4_9-branch.
// --- cut ---
int Fn
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/15789654
Fails with current trunk, and all older versions I've tried.
g++ -c t.cc -std=c++11
t.cc: In function 'void Bar()':
t.cc:9:11: error: uninitialized const member 'Foo::b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60265
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/15094102
The following test compiles with gcc-4.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61575
--- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Sorry, cut/paste error. Both
gcc-svn-4_9-r211828/bin/gcc
gcc-svn-4_9-r211175/bin/gcc
fails the same way.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Created attachment 32977
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32977action=edit
test case
Google ref: b/15734838
Test case compiles fine with Clang and current gcc-4_8-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61493
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58704
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61289
--- Comment #4 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Back-port to gcc-4_9-branch?
Thanks,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
--- Comment #4 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Still reproduces on current trunk @r211286
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
This appears to be a recent regression in trunk.
Source reduced from llvm/tools/clang/tools/clang-check/ClangCheck.cpp
Using trunk @r211286:
gcc-svn-r211286/bin/g++ -c t1.ii -std=c++11
t1.ii
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/15420505
Section 23.3.3.1 of C++11 shows the following typedef members of deque,
among others:
typedef typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61289
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57063
--- Comment #6 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Google ref: b/15091778
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
This worked as recently as r200178, is broken in at least r210292 and later.
struct Foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61242
--- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Forgot to mention: moving struct A and Create out of Foo and into global scope
fixes the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60970
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009
--- Comment #14 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Teresa Johnson from comment #13)
Thanks for the fix!
Indeed.
Confirming that it does indeed fix the application
issues we hit.
I will add that we've had
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/14657431
The test case compiles with Clang and gcc-4.6, fails with -DBUG on all later
versions including current trunk (r210292
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61023
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
--- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Still reproduces on current trunk at r210049
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
The test case:
#include typeinfo
struct Base {
virtual ~Base() { }
};
struct Derived : public Base {
};
int compare(const Base base)
{
return typeid(base) == typeid(typeid(Derived
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/14441040
// --- cut ---
template typename T struct Template {};
template typename O struct TemplateAliasStruct {
template typename T using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009
--- Comment #4 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Andrew Pinski from comment #2)
Most likely related to bug 60902.
Teresa, could you verify whether r209860 (for PR60902) fixes this one as well?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980
--- Comment #4 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Andrew Pinski from comment #3)
Note I think this code is invalid due to the struct not having a size.
Making the array non-empty makes no difference:
struct x0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978
--- Comment #7 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Richard Biener from comment #6)
Warns since forever (checked up to GCC 4.3.x), confirmed.
Interesting. In my non-reduced test case, the warning is new with gcc
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/14350545
Test:
/// --- cut ---
struct ScopeGuardGenerator { };
struct FF
{
template class F, class ... Ts
void
operator () (F
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Test case:
enum { A };
enum { B };
int foo(int x)
{
return x ? A : B;
}
gcc -c -Wall t.c
# no warnings
g++ -c t.c
t.c: In function ‘int foo(int)’:
t.c:6:12: warning: enumeral mismatch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978
--- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Andrew Pinski from comment #1)
This is documented to do this even in 4.8
(http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Warning-Options.html):
In C++ enumeral
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Test case:
struct x0
{
x0 () = default;
};
struct x1
{
x0 x2[];
void x3 ()
{
x1 ();
}
};
Using trunk @r209848 (2014-04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980
--- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Google ref: b/14366603
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Created attachment 32658
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32658action=edit
test case
Using trunk @r209546:
g++ -fdebug-types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60836
--- Comment #6 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Richard, back-port to 4.9/4.8 release branches?
Thanks,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60899
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59295
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60849
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/14002147
Using current trunk @r209347
gcc -c -O2 t.ii echo OK
OK
gcc -c -O2 t.ii -ftree-vectorize
t.ii: In function ‘double norm_(const int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/13644122
Reproduces with current trunk (r208944):
g++ -c -std=c++11 t.cc echo ok
ok
g++ -c -std=c++11 t.cc -O2
t.cc: In member function ‘void x6::x7()’:
t.cc:20:7: internal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57493
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57493
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54430
--- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com ---
From PR57493: Google ref: b/9229787
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54430
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57199
--- Comment #8 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Mikhail Veltishchev from comment #7)
Please, can you explain how you fixed this? We have almost the same problem.
Here is the fix we deployed (test case from
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Current trunk (r208813) and gcc-4.8 are affected, 4.7 does not appear to be.
gcc -O0 t.c ./a.out
500450210036
gcc -O3 t.c ./a.out
500450200033
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Using current trunk (r208813):
g++ -std=c++11 atomic.cc -latomic ./a.out
a.out: atomic.cc:20: int main(): Assertion `b.is_lock_free()' failed.
As far as I can tell, this is happening
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59295
--- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Still broken in current head (r208736).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59295
--- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com ---
This appears to be a very old warning.
Patch: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01123.html
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/13305941
Using current (r208339) trunk:
g++ -c -std=c++11 t.cc
t.cc: In instantiation of ‘struct fn(Iterator, Iterator
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Using current trunk (r208191):
g++ -c t.cc -std=c++11
t.cc:2:6: error: conflicting declaration 'auto i'
auto i = j;
^
t.cc:1:12: note: previous declaration
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
std::deque currently leaks memory. Test case:
#include deque
int main()
{
for (int j = 0; j 10; ++j)
{
const int ia[] = { 2, 3, 1, 4, 2, 1, 3, 0 };
std::dequeint d(ia, ia
1 - 100 of 274 matches
Mail list logo
