From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13972 invoked by alias); 20 Jun 2014 05:34:42 -0000 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 Received: (qmail 13937 invoked by uid 48); 20 Jun 2014 05:34:38 -0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug testsuite/61567] gfortran.dg/coarray_collectives_{5,6}.f90 failure Date: Fri, 20 Jun 2014 05:34:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: testsuite X-Bugzilla-Version: 4.10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-06/txt/msg01660.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D61567 Tobias Burnus changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tobias Burnus --- FIXED. Thanks for the report and sorry for the breakage. When testing what became r211816, I wondered why it didn't require testsuite changes =E2=80=93 well,= it turned out it did, but I had looked at the wrong testsuite log file. >>From gcc-bugs-return-454579-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 20 06:07:35 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 17724 invoked by alias); 20 Jun 2014 06:07:34 -0000 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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 17666 invoked by uid 48); 20 Jun 2014 06:07:25 -0000 From: "n-gcc at nn dot kiev.ua" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/61569] New: faggressive-loop-optimizations overoptimize loop checks with unpredicted result Date: Fri, 20 Jun 2014 06:07:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 4.8.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: n-gcc at nn dot kiev.ua X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-06/txt/msg01661.txt.bz2 Content-length: 2217 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61569 Bug ID: 61569 Summary: faggressive-loop-optimizations overoptimize loop checks with unpredicted result Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: n-gcc at nn dot kiev.ua The following program performs 112 iterations (and stop on x==1) instead of expected 10 ones. #include int main() { int i, x = 27; for (i = 0; i < 10; ++i) { printf("%11d : %11d : %d\n", i, i*1000000000, x); if (x==1) break; x = x%2 ? x*3+1 : x/2; } return 0; } With a small change, it, instead, limits itself to 3 iterations. #include int main() { int i, j, x = 27; for (i = j = 0; i < 10; ++i, ++j) { printf("%11d : %11d : %d\n", i, j*1000000000, x); if (x==1) break; x = x%2 ? x*3+1 : x/2; } return 0; } Conditions to represent the issue are: 1. gcc after 4.8.0 (my versions gcc48-4.8.4.s20140605 and gcc49-4.9.1.s20140611 from FreeBSD ports). 2. -O2 or higher, or -Os. The issue goes after any of the following options added: * -fno-aggressive-loop-optimizations * -fno-strict-overflow * -fwrapv or -ftrapv (obviously) Stage dump analysis shows that loop exit condition check (i<10 in that code examples, i<=9 internally after some change) is gone away at 056t.cunrolli. Adding of -Wstrict-overflow of any level doesn't cause warning emission. The similar issue was reported in #58143 comment 9, and #53265 seems devoted to lack of warning, but I'm not sure cases are equal. Disclaimer: I'm aware of standard's statement "signed integer overflow is UB" but I'm confident that a respected common-goal compiler should thoroughly limit this UB to result value of the operator itself and avoid expanding it to any other program action. Thanks to: livejournal.com user _winnie for issue finding; user kodt_rsdn (Nikolay Merkin) for the clear example designing; Serge Ryabchun for diagnosing -faggressive-loop-optimizations influence.