From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18002 invoked by alias); 22 Oct 2013 07:08:28 -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 17953 invoked by uid 48); 22 Oct 2013 07:08:24 -0000 From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/58779] [4.7/4.8/4.9 Regression] wrong code at -O1 on x86_64-linux-gnu Date: Tue, 22 Oct 2013 07:08:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: ubizjak at gmail dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ubizjak at gmail dot com X-Bugzilla-Target-Milestone: 4.7.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: 2013-10/txt/msg01573.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D58779 --- Comment #5 from Uro=C5=A1 Bizjak --- combine pass is converting: (insn 21 20 22 4 (parallel [ (set (reg:SI 73) (minus:SI (reg:SI 64 [ a.2 ]) (reg:SI 59 [ iftmp.3 ]))) (clobber (reg:CC 17 flags)) ]) pr58779.c:8 286 {*subsi_1} (expr_list:REG_DEAD (reg:SI 59 [ iftmp.3 ]) (expr_list:REG_UNUSED (reg:CC 17 flags) (nil)))) (insn 22 21 23 4 (set (reg:CC 17 flags) (compare:CC (reg:SI 64 [ a.2 ]) (reg:SI 73))) pr58779.c:8 6 {*cmpsi_1} (expr_list:REG_DEAD (reg:SI 73) (expr_list:REG_DEAD (reg:SI 64 [ a.2 ]) (nil)))) (jump_insn 23 22 24 4 (set (pc) (if_then_else (ltu (reg:CC 17 flags) (const_int 0 [0])) (label_ref 27) (pc))) pr58779.c:8 596 {*jcc_1} (expr_list:REG_DEAD (reg:CC 17 flags) (expr_list:REG_BR_PROB (const_int 9996 [0x270c]) (nil))) to: (insn 22 21 23 4 (set (reg:CCC 17 flags) (compare:CCC (minus:SI (reg:SI 64 [ a.2 ]) (reg:SI 59 [ iftmp.3 ])) (reg:SI 64 [ a.2 ]))) pr58779.c:8 316 {*subsi3_cconly_overflow} (expr_list:REG_DEAD (reg:SI 59 [ iftmp.3 ]) (expr_list:REG_DEAD (reg:SI 64 [ a.2 ]) (nil)))) (jump_insn 23 22 24 4 (set (pc) (if_then_else (gtu (reg:CCC 17 flags) (const_int 0 [0])) (label_ref 27) (pc))) pr58779.c:8 596 {*jcc_1} (expr_list:REG_DEAD (reg:CC 17 flags) (expr_list:REG_BR_PROB (const_int 9996 [0x270c]) (nil))) To satisfy the *subsi3_cconly_overflow pattern, the operands of the compare= are swapped, and this reflects in changing jump insn condition from LTU to GTU. The LTU in CCmode results in "jb" instruction, whereas GTU in CCCmode in unpatched gcc also results in "jb". As Mikael figured out in Comment #2, we should jump on Not-Carry condition here. It looks to me that MINUS overflow checks are NOT modelled correctly. To hi= de this problem, GTU and LEU conditions operate with inverted flag check, as c= an be seen in i386.c, put_condition_code: case GTU: if (mode =3D=3D CCmode) suffix =3D fp ? "nbe" : "a"; else if (mode =3D=3D CCCmode) suffix =3D "b"; ... case LEU: if (mode =3D=3D CCmode) suffix =3D "be"; else if (mode =3D=3D CCCmode) suffix =3D fp ? "nb" : "ae"; ... As can be seen from the above code, hecks in CCCmode are inverted. So, the solution is simply to remove wrong MINUS overflow checks, as in to-= be attached patch. >>From gcc-bugs-return-432430-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Oct 22 07:09:31 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 19234 invoked by alias); 22 Oct 2013 07:09:31 -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 19179 invoked by uid 48); 22 Oct 2013 07:09:28 -0000 From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/58779] [4.7/4.8/4.9 Regression] wrong code at -O1 on x86_64-linux-gnu Date: Tue, 22 Oct 2013 07:09:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: ubizjak at gmail dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ubizjak at gmail dot com X-Bugzilla-Target-Milestone: 4.7.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created 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: 2013-10/txt/msg01574.txt.bz2 Content-length: 289 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D58779 --- Comment #6 from Uro=C5=A1 Bizjak --- Created attachment 31067 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=3D31067&action=3Dedit Proposed patch that removes MINUS overflow checks Patch in testing. >>From gcc-bugs-return-432431-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Oct 22 07:45:49 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 10958 invoked by alias); 22 Oct 2013 07:45:48 -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 10930 invoked by uid 48); 22 Oct 2013 07:45:44 -0000 From: "dougkwan at google dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/58838] New: mullw sets condition code incorrectly. Date: Tue, 22 Oct 2013 07:45:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dougkwan at google 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-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: 2013-10/txt/msg01575.txt.bz2 Content-length: 3174 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58838 Bug ID: 58838 Summary: mullw sets condition code incorrectly. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dougkwan at google dot com It was observed in 4.7 and trunk that the Power backend generated bad code involving condition setting mullw. Below is a test case for the problem: ----- #include #include #include struct b88 { char data[88]; }; namespace { inline int int_size(const std::vector& v) { return v.size(); } } int __attribute__ ((noinline)) foo(const std::vector& v) { if (int_size(v) > 0) { return atoi("1"); } return 0; } int main() { std::vector v; v.push_back(b88()); assert(foo(v) != 0); return 0; } ---- The above test failed with gcc 4.7 and trunk for target powerpc64-linux-gnu We seem to be fine getting out of the middle-end of gcc-4.7: ;; Function int foo(const std::vector&) (_Z3fooRKSt6vectorI3b88SaIS0_EE, funcdef_no=473, decl_uid=9136, cgraph_uid=102) int foo(const std::vector&) (const struct vector & v) { int _1; struct b88 * _4; struct b88 * _5; long int _6; long int _7; long int _8; long int _9; int _10; long int _11; int _12; : _4 = MEM[(const struct vector *)v_3(D)]; _5 = MEM[(const struct vector *)v_3(D) + 8B]; _6 = (long int) _5; _7 = (long int) _4; _8 = _6 - _7; _9 = _8 /[ex] 88; _10 = (int) _9; if (_10 > 0) goto ; else goto ; : _11 = strtol ("1", 0B, 10); _12 = (int) _11; : # _1 = PHI <_12(3), 0(2)> return _1; } RTL expansion looks correct, gcc expands "_8 /[ex] 88;" into shift and multiplication. (_8 >> 3) * 0x2e8ba2e8ba2e8ba3. Since we know that the _8 is a multiple of 88, we can do this. 0x2e8ba2e8ba2e8ba3 is the multiplicative-inverse of 11 in Z{2^64}. But the selected PPC instruction is bad: 0x10000b80 <._Z3fooRKSt6vectorI3b88SaIS0_EE>: lis r9,11915 0x10000b84 <._Z3fooRKSt6vectorI3b88SaIS0_EE+4>: ld r8,8(r3) 0x10000b88 <._Z3fooRKSt6vectorI3b88SaIS0_EE+8>: ld r10,0(r3) 0x10000b8c <._Z3fooRKSt6vectorI3b88SaIS0_EE+12>: ori r9,r9,41704 0x10000b90 <._Z3fooRKSt6vectorI3b88SaIS0_EE+16>: rldicr r9,r9,32,31 0x10000b94 <._Z3fooRKSt6vectorI3b88SaIS0_EE+20>: subf r10,r10,r8 0x10000b98 <._Z3fooRKSt6vectorI3b88SaIS0_EE+24>: oris r9,r9,47662 0x10000b9c <._Z3fooRKSt6vectorI3b88SaIS0_EE+28>: sradi r10,r10,3 0x10000ba0 <._Z3fooRKSt6vectorI3b88SaIS0_EE+32>: ori r9,r9,35747 0x10000ba4 <._Z3fooRKSt6vectorI3b88SaIS0_EE+36>: mullw. r8,r10,r9 <================ note the "dot" 0x10000ba8 <._Z3fooRKSt6vectorI3b88SaIS0_EE+40>: ble 0x10000bf0 <._Z3fooRKSt6vectorI3b88SaIS0_EE+112> mullw correctly computes the lower 32-bits of "_9 = _8 /[ex] 88;" but it sets the condition code incorrectly, since signed-comparison is done in 64 bits. Instead there should be sign extension, ie. mullw r8,r10,r9 extsw. r8,r8