[Bug c++/50592] New: g++ fails to see function side effect

[nospam.gccboostix.20.lenex at spamgourmet dot com]

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: unassig...@gcc.gnu.org
        ReportedBy: nospam.gccboostix.20.le...@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.