[Bug c++/50592] New: g++ fails to see function side effect
nospam.gccboostix.20.lenex at spamgourmet dot com
gcc-bugzilla@gcc.gnu.org
Sun Oct 2 17:21:00 GMT 2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50592
Bug #: 50592
Summary: g++ fails to see function side effect
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: nospam.gccboostix.20.lenex@spamgourmet.com
Hello,
I’m currently facing a problem with a program using boost:
https://svn.boost.org/trac/boost/ticket/4452
But after having had a deeper look on it, I think that the problem is coming
from gcc because the occurrence of the problem depends on the optimization
level (I have deactivated strict aliasing rule since it is a known case of
breakage of wrong code) and appears only with gcc 4.5 and 4.6. With gcc 4.4,
the program works fine.
(The exact versions tested were: 4.4.6 (OK), 4.5.3 (KO) and 4.6.1 (KO). All on
x86_64-linux-gnu)
I have attached a pre-processed program that reproduces the issue.
It behaves differently depending on the optimization level.
When compiled without any optimization with
g++ -Wall -Wextra -o testboost testboost.i -g -lrt
The program exits normally
When compiled with optimization with
g++ -Wall -Wextra -o testboost testboost.i -g -O1 -fno-strict-aliasing -lrt
The program issue a segmentation error.
What’s even more weird is what happens when the following line of testboost.i
is uncommented:
//abort(); // Uncommenting this abort makes this program work.
Then, the program exits normally.
This indicates that:
— this line and this abort are in a path that is not executed by this program
(otherwise, the program wouldn’t have exited normally.);
— adding this line has a deep impact on the code generated.
Here is the stack that lead to the execution of the function that contains that
abort:
#0 boost::intrusive::detail::tree_algorithms<…>::insert_commit (…) at
…/tree_algorithms.hpp:907
#1 0x0000000000406bdd in insert_equal_upper_bound<…> (…) at
…/tree_algorithms.hpp:1071
#2 insert_equal_upper_bound<…> (…) at …/rbtree_algorithms.hpp:538
#3 insert_equal (…) at …/rbtree.hpp:482
#4 insert (…) at …/set.hpp:1569
#5 boost::interprocess::rbtree_best_fit<…>::priv_add_segment (…) at
…/rbtree_best_fit.hpp:538
…
#14 main () at testboost.cpp:11
And here is the stack of the segmentation fault:
#0 get_color (…) at …/rbtree_node.hpp:136
#1 boost::intrusive::rbtree_algorithms<…>::rebalance_after_insertion (…) at
…/rbtree_algorithms.hpp:855
#2 0x0000000000406bbd in insert_equal_upper_bound<…> (…) at
…/rbtree_algorithms.hpp:539
#3 insert_equal (…) at …/rbtree.hpp:482
#4 insert (…) at …/set.hpp:1569
#5 boost::interprocess::rbtree_best_fit<…>::priv_add_segment (…) at
…/rbtree_best_fit.hpp:538
…
#14 main () at testboost.cpp:11
When, in gdb, I put a breakpoint in the function that contains (or not) the
abort, when the abort is commented, the program segfaults without hitting the
breakpoint.
This observation makes me wonder if a gcc optimization may have missed a side
effect of a piece of code and decided to skip, or at least to delay, its
execution.
Even when looking at the generated assembler code, I have the feeling that
insert_commit is not called when the abort is left commented.
More information about the Gcc-bugs
mailing list