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 f
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 reference
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 (__mutex=
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 #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=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=67396
--- Comment #5 from Paul Pluzhnikov ---
> 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; still very slow):
for j in 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67396
--- Comment #3 from Paul Pluzhnikov ---
(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 times (seconds)
phase se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67396
Paul Pluzhnikov changed:
What|Removed |Added
CC||jh at suse dot cz
--- Comment #1 from
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=36270&action=ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61022
--- Comment #2 from Paul Pluzhnikov ---
Still fails with trunk @r222386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
--- Comment #7 from Paul Pluzhnikov ---
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=65287
--- Comment #1 from Paul Pluzhnikov ---
Created attachment 34928
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34928&action=edit
c-reduce'd test case
A much shorter test:
const int __new_sys_siglist[] = {};
extern __typeof(__new_sys_sig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65263
--- Comment #10 from Paul Pluzhnikov ---
(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
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=34927&action=edit
test case
Continued from PR 65263
r221040 is also possibly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65263
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978
--- Comment #11 from Paul Pluzhnikov ---
(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 part of kernel, not glibc itsel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978
--- Comment #9 from Paul Pluzhnikov ---
(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.
They are?
In glibc-2.19, include/netin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61022
--- Comment #1 from Paul Pluzhnikov ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63540
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63149
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62310
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
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 (_F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59812
--- Comment #3 from Paul Pluzhnikov ---
Reconfirmed @r212875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59815
--- Comment #3 from Paul Pluzhnikov ---
Still broken @r212875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
--- Comment #6 from Paul Pluzhnikov ---
Still broken @r212875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44122
Paul Pluzhnikov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61833
Paul Pluzhnikov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723
--- Comment #8 from Paul Pluzhnikov ---
Filed PR61833
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Created attachment 33134
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33134&action=edit
test case
Google ref: b/16030670
Originally reported against gcc-4.8.
Attached test case causes gcc-4_9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723
--- Comment #6 from Paul Pluzhnikov ---
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, the reduced test also ICEd on trunk.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723
--- Comment #5 from Paul Pluzhnikov ---
(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 user type
In the non-reduce
++
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=59832
--- Comment #5 from Paul Pluzhnikov ---
Still broken on trunk @r211990.
Any chance someone can look at this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58930
--- Comment #5 from Paul Pluzhnikov ---
(In reply to Paolo Carlini from comment #4)
> Fixed for 4.10.0.
Can this be back-ported to gcc-4_9-branch?
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61575
--- Comment #1 from Paul Pluzhnikov ---
Sorry, cut/paste error. Both
gcc-svn-4_9-r211828/bin/gcc
gcc-svn-4_9-r211175/bin/gcc
fails the same way.
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 and t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60265
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
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=32977&action=edit
test case
Google ref: b/15734838
Test case compiles fine with Clang and current gcc-4_8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58704
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61493
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61289
--- Comment #4 from Paul Pluzhnikov ---
Back-port to gcc-4_9-branch?
Thanks,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
--- Comment #4 from Paul Pluzhnikov ---
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 changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61242
--- Comment #1 from Paul Pluzhnikov ---
Forgot to mention: moving struct A and Create out of Foo and into global scope
fixes the problem.
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
{
struct A
{
const int &contai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57063
--- Comment #6 from Paul Pluzhnikov ---
Google ref: b/15091778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60970
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
Severity: 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 trun
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009
--- Comment #14 from Paul Pluzhnikov ---
(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 at least two separate miscompi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61023
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
--- Comment #3 from Paul Pluzhnikov ---
Still reproduces on current trunk at r210049
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/14441040
// --- cut ---
template struct Template {};
template struct TemplateAliasStruct {
template using Temp
iority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
The test case:
#include
struct Base {
virtual ~Base() { }
};
struct Derived : public Base {
};
int compare(const Base& base)
{
return typeid(base) == typeid(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009
--- Comment #4 from Paul Pluzhnikov ---
(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=61009
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978
--- Comment #7 from Paul Pluzhnikov ---
(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-4.9.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980
--- Comment #4 from Paul Pluzhnikov ---
(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
{
x0 () = default;
};
stru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980
--- Comment #1 from Paul Pluzhnikov ---
Google ref: b/14366603
: 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=60978
--- Comment #2 from Paul Pluzhnikov ---
(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 mismatches in conditional expr
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 in
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=32658&action=edit
test case
Using trunk @r209546:
g++ -fdebu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60836
--- Comment #6 from Paul Pluzhnikov ---
Richard, back-port to 4.9/4.8 release branches?
Thanks,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60899
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59295
Paul Pluzhnikov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60849
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
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 nor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
: 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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54430
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54430
--- Comment #3 from Paul Pluzhnikov ---
>From PR57493: Google ref: b/9229787
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57493
Paul Pluzhnikov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57493
Paul Pluzhnikov changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #3 from Paul Pluz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57199
--- Comment #8 from Paul Pluzhnikov ---
(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 comment#2):
$ diff -u pr57199.c
: 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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59295
--- Comment #2 from Paul Pluzhnikov ---
This appears to be a very old warning.
Patch: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01123.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59295
--- Comment #1 from Paul Pluzhnikov ---
Still broken in current head (r208736).
s: UNCONFIRMED
Severity: 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(Iter
Severity: normal
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:
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
std::deque currently leaks memory. Test case:
#include
int main()
{
for (int j = 0; j < 10; ++j)
{
const int ia[] = { 2, 3, 1, 4, 2, 1, 3, 0 };
std::deque d(ia, ia + siz
1 - 100 of 274 matches
Mail list logo
