From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13927 invoked by alias); 2 Oct 2011 17:21:14 -0000 Received: (qmail 13906 invoked by uid 22791); 2 Oct 2011 17:21:13 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_LR X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 02 Oct 2011 17:20:59 +0000 From: "nospam.gccboostix.20.lenex at spamgourmet dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/50592] New: g++ fails to see function side effect Date: Sun, 02 Oct 2011 17:21:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: nospam.gccboostix.20.lenex at spamgourmet dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00055.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D50592 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=E2=80=99m 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=E2=80=99s even more weird is what happens when the following line of t= estboost.i is uncommented: //abort(); // Uncommenting this abort makes this program work. Then, the program exits normally. This indicates that: =E2=80=94 this line and this abort are in a path that is not executed by th= is program (otherwise, the program wouldn=E2=80=99t have exited normally.); =E2=80=94 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<=E2=80=A6>::insert_commit (= =E2=80=A6) at =E2=80=A6/tree_algorithms.hpp:907 #1 0x0000000000406bdd in insert_equal_upper_bound<=E2=80=A6> (=E2=80=A6) at =E2=80=A6/tree_algorithms.hpp:1071 #2 insert_equal_upper_bound<=E2=80=A6> (=E2=80=A6) at =E2=80=A6/rbtree_alg= orithms.hpp:538 #3 insert_equal (=E2=80=A6) at =E2=80=A6/rbtree.hpp:482 #4 insert (=E2=80=A6) at =E2=80=A6/set.hpp:1569 #5 boost::interprocess::rbtree_best_fit<=E2=80=A6>::priv_add_segment (=E2= =80=A6) at =E2=80=A6/rbtree_best_fit.hpp:538 =E2=80=A6 #14 main () at testboost.cpp:11 And here is the stack of the segmentation fault: #0 get_color (=E2=80=A6) at =E2=80=A6/rbtree_node.hpp:136 #1 boost::intrusive::rbtree_algorithms<=E2=80=A6>::rebalance_after_inserti= on (=E2=80=A6) at =E2=80=A6/rbtree_algorithms.hpp:855 #2 0x0000000000406bbd in insert_equal_upper_bound<=E2=80=A6> (=E2=80=A6) at =E2=80=A6/rbtree_algorithms.hpp:539 #3 insert_equal (=E2=80=A6) at =E2=80=A6/rbtree.hpp:482 #4 insert (=E2=80=A6) at =E2=80=A6/set.hpp:1569 #5 boost::interprocess::rbtree_best_fit<=E2=80=A6>::priv_add_segment (=E2= =80=A6) at =E2=80=A6/rbtree_best_fit.hpp:538 =E2=80=A6 #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 t= he breakpoint. This observation makes me wonder if a gcc optimization may have missed a si= de 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.