[Bug c++/61751] New: Empty brace-initializer causes double destruction of unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61751
Bug ID: 61751
Summary: Empty brace-initializer causes double destruction of
unique_ptr
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: perso...@e-maxx.ru
Created attachment 33091
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33091&action=edit
Full example.
Use of empty brace-initializer in default function argument causes strange
effects and, finally, crashes.
The minimal code is:
#include
class A {
std::unique_ptr ptr_;
public:
A() : ptr_(new int(123))
{ }
A(A&& other) : ptr_(std::move(other.ptr_))
{ }
};
void f(A a)
{ }
void g(A a = {}) // replace "{}" with "A()" makes it work
{ f(std::move(a)); }
int main()
{ g(); }
There is a more detailed example in the attachment, which produces some debug
output, e.g.:
A() called [this=0x7bac34f0, constructed unique_ptr=0xe18010]
A(A&&) called [this=0x7bac34b0, other=0x7bac34d0]
~A() called [this=0x7bac34b0, unique_ptr=0xe18010]
~A() called [this=0x7bac34f0, unique_ptr=0xe18010]
*** glibc detected *** ./a.out: double free or corruption (fasttop):
0x00e18010 ***
On the contrary, using some correct version of compiler (I tried 4.6.3 and
4.9.0) we get:
A() called [this=0x7fff77c52810, constructed unique_ptr=0xe1c010]
A(A&&) called [this=0x7fff77c527e0, other=0x7fff77c52810]
~A() called [this=0x7fff77c527e0, unique_ptr=0xe1c010]
~A() called [this=0x7fff77c52810, unique_ptr=0]
As it can be seen, the difference is that the bogus version moves from object
that has never been constructed.
[Bug c++/48695] New: Runtime with an array of std::vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48695
Summary: Runtime with an array of std::vectors
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: perso...@e-maxx.ru
Created attachment 24048
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24048
The entire program
The following program crashes if compiled with -O2:
for (int i=0; i<=1; i++)
for (int j=0; j<=1; j++) {
std::vector a[2];
a[i].push_back (0);
}
If we remove any 'for' loop, or if we change a[i] to a[0] or to a[1] - there
will be no crash.
[Bug tree-optimization/48837] New: Wrong optimization of recursive function calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837 Summary: Wrong optimization of recursive function calls Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: perso...@e-maxx.ru Created attachment 24153 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24153 The example program - it should output "ans = 1", but outputs "ans = 0" in -O2 The program attached outputs "global ans = 1" if compiled without optimizations, and "global ans = 0" with -O2 set. Moreover, if we insert debug-output into the recursive function, it becomes working right: //cout << "query = " << ans << endl; // ^ UNCOMMENT THIS LINE TO MAKE THE PROGRAM WORK OK If we uncomment the line, the program outputs "global ans = 1" both with -O2 and without it. Unfortunately, I couldn't make the test program very simple - optimizer works OK on simple programs, but when we have a complex recursion calls - it starts making wrong code. To make you understand it better - there are some additional debug-outputs. For example, the right program flow results in the following output: call auxillary (t[9], 123): auxillary = 1 call auxillary (t[5], 123): auxillary = 0 global ans = 1 When we compile with -O2, the output becomes: call auxillary (t[9], 123): auxillary = 1 call auxillary (t[5], 123): auxillary = 0 global ans = 0 (note that from code we can see that query() returns sum of all recursive answers - then how can it return 0, if one auxillary() returned 1???)
[Bug tree-optimization/48837] Wrong optimization of recursive function calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837 --- Comment #2 from e-maxx 2011-05-01 06:13:59 UTC --- It affects even 4.4.3.
[Bug tree-optimization/49217] New: Wrong optimization of code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49217 Summary: Wrong optimization of code Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: perso...@e-maxx.ru Created attachment 24387 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24387 The program demostrating the bug (should return 0 if OK, but throws in case of wrong optimization) A bug in gcc 4.6.0 optimizer leads to incorrect program flow. It looks like this exact bug is difficult to reproduce in small program, so the attached program is a result of my minimization. The bug requires quite complex environment: recursive function, std::vector, std::vector::iterator, zeroing the global array, unreachable 'else'. Though, I think, the main idea of the program is not so difficult: we call DFS(0), it calls DFS(1), and as a result both 0 and 1 are marked as visited, so the number of calls of DFS() from main() is equal to one. But in g++ 4.6.0 with -O2 that's not true (it looks like DFS(0) never calls DFS(1), but that's my hypothesis). Inserting cerr or cout into some places of DFS makes the program work fine.
[Bug tree-optimization/49218] New: Incorrect optimization of a 'for' loop creates an infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49218 Summary: Incorrect optimization of a 'for' loop creates an infinite loop Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: perso...@e-maxx.ru Created attachment 24388 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24388 The program reads a number, and then it should output it back. After incorrect optimization, however, the program hangs up The following small program hangs up if compiled under gcc 4.6 with -O2. The program reads a number (it can be any number, '5' for example), and then it performs some silly for-loop, and then it should output the same number. In gcc 4.6 with -O2, however, the program hangs up without outputting anything. It looks like the loop (which can be doing less that 10 operations in reality) is 'optimized' into an infinite loop.
