public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/60562] New: ’4.9 Regression] FAIL: gcc.target/i386/excess-precision-3.c execution test on x86_64-apple-darwin13
@ 2014-03-18 9:59 dominiq at lps dot ens.fr
2014-03-18 11:48 ` [Bug target/60562] [4.9 " rguenth at gcc dot gnu.org
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-03-18 9:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60562
Bug ID: 60562
Summary: ’4.9 Regression] FAIL:
gcc.target/i386/excess-precision-3.c execution test on
x86_64-apple-darwin13
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dominiq at lps dot ens.fr
CC: iains at gcc dot gnu.org, rth at gcc dot gnu.org
Host: x86_64-apple-darwin1*
Target: x86_64-apple-darwin1*
Build: x86_64-apple-darwin1*
The test gcc.target/i386/excess-precision-3.c has started to fail at run time
on x86_64-apple-darwin1* between revisions r208581 (pass) and r208594 (fail).
AFAICT the only relevant changes in this range are in r208587.
>From gcc-bugs-return-446663-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 18 10:08:14 2014
Return-Path: <gcc-bugs-return-446663-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8162 invoked by alias); 18 Mar 2014 10:08:14 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8118 invoked by uid 48); 18 Mar 2014 10:08:10 -0000
From: "amker.cheng at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug regression/60363] [4.9 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 "Threaded" 4
Date: Tue, 18 Mar 2014 10:08:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: regression
X-Bugzilla-Version: 4.7.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amker.cheng at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60363-4-2LHw2SXEWM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60363-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60363-4@http.gcc.gnu.org/bugzilla/>
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-03/txt/msg01532.txt.bz2
Content-length: 6721
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363
--- Comment #8 from bin.cheng <amker.cheng at gmail dot com> ---
Here is the findings.
1) After patching 208165, there are two more jump threading opportunities for
dom1 pass. Jump threading is doing alright, the interesting thing is why there
is no such opportunities before patching. The two additional opportunities are
introduced after vrp1.
VRP1 dump without patch:
<bb 2>:
goto <bb 15>;
<bb 3>:
if (b_elt_11(D) != 0B)
goto <bb 4>;
else
goto <bb 8>;
<bb 4>:
goto <bb 6>;
<bb 5>:
kill_elt_14 = kill_elt_2->next;
<bb 6>:
# kill_elt_2 = PHI <kill_elt_4(4), kill_elt_14(5)>
if (kill_elt_2 != 0B)
goto <bb 7>;
else
goto <bb 19>;
<bb 7>:
_12 = kill_elt_2->indx;
_13 = b_elt_11(D)->indx;
if (_12 < _13)
goto <bb 5>;
else
goto <bb 18>;
<bb 8>:
# kill_elt_3 = PHI <kill_elt_4(3)>
if (b_elt_11(D) != 0B)
goto <bb 9>;
else
goto <bb 14>;
<bb 9>:
if (kill_elt_3 != 0B)
goto <bb 10>;
else
goto <bb 14>;
<bb 10>:
# kill_elt_32 = PHI <kill_elt_3(9), kill_elt_39(18)>
_15 = kill_elt_32->indx;
_16 = b_elt_11(D)->indx;
if (_15 == _16)
goto <bb 11>;
else
goto <bb 14>;
<bb 11>:
if (a_elt_9(D) == 0B)
goto <bb 13>;
else
goto <bb 12>;
<bb 12>:
_17 = a_elt_9(D)->indx;
if (_16 <= _17)
goto <bb 13>;
else
goto <bb 14>;
<bb 13>:
_20 = (int) changed_1;
_25 = bitmap_elt_ior (dst_21(D), dst_elt_22(D), dst_prev_23(D), a_elt_9(D),
&tmp_elt, _20);
changed_26 = (unsigned char) _25;
tmp_elt ={v} {CLOBBER};
<bb 14>:
# changed_18 = PHI <changed_26(13), changed_1(8), changed_1(9),
changed_1(10), changed_1(12), changed_1(18), changed_1(19)>
# kill_elt_33 = PHI <kill_elt_32(13), kill_elt_3(8), kill_elt_3(9),
kill_elt_32(10), kill_elt_32(12), kill_elt_39(18), kill_elt_35(19)>
<bb 15>:
# changed_1 = PHI <changed_18(14), 0(2)>
# kill_elt_4 = PHI <kill_elt_33(14), kill_elt_7(D)(2)>
if (a_elt_9(D) != 0B)
goto <bb 3>;
else
goto <bb 16>;
<bb 16>:
if (b_elt_11(D) != 0B)
goto <bb 3>;
else
goto <bb 17>;
<bb 17>:
# changed_6 = PHI <changed_1(16)>
changed_28 = changed_6;
return changed_28;
<bb 18>:
# kill_elt_39 = PHI <kill_elt_2(7)>
if (b_elt_11(D) != 0B)
goto <bb 10>;
else
goto <bb 14>;
<bb 19>:
# kill_elt_35 = PHI <0B(6)>
goto <bb 14>;
VRP1 dump with patch:
<bb 2>:
goto <bb 15>;
<bb 3>:
if (b_elt_11(D) != 0B)
goto <bb 4>;
else
goto <bb 8>;
<bb 4>:
# kill_elt_10 = PHI <kill_elt_4(3)>
goto <bb 6>;
<bb 5>:
kill_elt_14 = kill_elt_2->next;
<bb 6>:
# kill_elt_2 = PHI <kill_elt_10(4), kill_elt_14(5)>
if (kill_elt_2 != 0B)
goto <bb 7>;
else
goto <bb 19>;
<bb 7>:
_12 = kill_elt_2->indx;
_13 = b_elt_11(D)->indx;
if (_12 < _13)
goto <bb 5>;
else
goto <bb 20>;
<bb 8>:
# kill_elt_3 = PHI <kill_elt_4(3)>
if (b_elt_11(D) != 0B)
goto <bb 9>;
else
goto <bb 14>;
<bb 9>:
if (kill_elt_3 != 0B)
goto <bb 10>;
else
goto <bb 14>;
<bb 10>:
# kill_elt_34 = PHI <kill_elt_3(9), kill_elt_37(20)>
_15 = kill_elt_34->indx;
_16 = b_elt_11(D)->indx;
if (_15 == _16)
goto <bb 11>;
else
goto <bb 14>;
<bb 11>:
if (a_elt_9(D) == 0B)
goto <bb 13>;
else
goto <bb 12>;
<bb 12>:
_17 = a_elt_9(D)->indx;
if (_16 <= _17)
goto <bb 13>;
else
goto <bb 14>;
<bb 13>:
_20 = (int) changed_1;
_25 = bitmap_elt_ior (dst_21(D), dst_elt_22(D), dst_prev_23(D), a_elt_9(D),
&tmp_elt, _20);
changed_26 = (unsigned char) _25;
tmp_elt ={v} {CLOBBER};
<bb 14>:
# changed_19 = PHI <changed_1(8), changed_1(18), changed_26(13),
changed_1(12), changed_1(10), changed_1(19), changed_1(20), changed_1(9)>
# kill_elt_18 = PHI <kill_elt_3(8), 0B(18), kill_elt_34(13), kill_elt_34(12),
kill_elt_34(10), kill_elt_41(19), kill_elt_37(20), 0B(9)>
<bb 15>:
# changed_1 = PHI <changed_19(14), 0(2)>
# kill_elt_4 = PHI <kill_elt_18(14), kill_elt_7(D)(2)>
if (a_elt_9(D) != 0B)
goto <bb 3>;
else
goto <bb 16>;
<bb 16>:
if (b_elt_11(D) != 0B)
goto <bb 3>;
else
goto <bb 17>;
<bb 17>:
# changed_29 = PHI <changed_1(16)>
changed_28 = changed_29;
return changed_28;
<bb 18>:
goto <bb 14>;
<bb 19>:
# kill_elt_41 = PHI <0B(6)>
if (b_elt_11(D) != 0B)
goto <bb 18>;
else
goto <bb 14>;
<bb 20>:
# kill_elt_37 = PHI <kill_elt_2(7)>
if (b_elt_11(D) != 0B)
goto <bb 10>;
else
goto <bb 14>;
The problem part is as below:
<bb 14>:
# changed_19 = PHI <changed_1(8), changed_1(18), changed_26(13),
changed_1(12), changed_1(10), changed_1(19), changed_1(20), changed_1(9)>
# kill_elt_18 = PHI <kill_elt_3(8), 0B(18), kill_elt_34(13), kill_elt_34(12),
kill_elt_34(10), kill_elt_41(19), kill_elt_37(20), 0B(9)>
...
<bb 18>:
goto <bb 14>;
<bb 19>:
# kill_elt_41 = PHI <0B(6)>
if (b_elt_11(D) != 0B)
goto <bb 18>;
else
goto <bb 14>;
Since PHI argument "kill_elt_41(19)" equals to "0B(18)", the bb18 is a
removable forward basic block. By removing bb18, bb19 can be simplified into a
single jump to bb14 too. This is exactly what GCC does without patch.
When CFGcleanup tries to remove bb18, it has to check that PHI arguments
"kill_elt_41(19)" and "0B(18)" are compatible. Unfortunately, CFGcleanup
doesn't evaluate value of ssa_name and it doesn't know that "kill_elt_41(19)"
equals to "0" along jump threading path "19->14".
Since jump threading is now a flow sensitive optimization, it knows very well
about that truth, so I come up below conclusion:
Jump threading adds PHI argument by copying existing one when duplicating basic
blocks along jump threading path. It’s very possible that a PHI argument has a
constant value along threading path, but jump threading doesn’t do any value
evaluation and just copies the ssa_name. If we copy the constant value instead
of ssa_name, cfgcleanup after jump threading can see more removable forward
basic blocks thus the issue is fixed.
For this specific case, jump threading should be able to add argument "0(19)"
rather than "kill_elt_41(19)" to bb14, like:
<bb 14>:
# changed_19 = PHI <changed_1(8), changed_1(18), changed_26(13),
changed_1(12), changed_1(10), changed_1(19), changed_1(20), changed_1(9)>
# kill_elt_18 = PHI <kill_elt_3(8), 0B(18), kill_elt_34(13), kill_elt_34(12),
kill_elt_34(10), 0(19), kill_elt_37(20), 0B(9)>
I worked out a patch fixing the issue, will send it for review.
>From gcc-bugs-return-446664-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 18 10:11:58 2014
Return-Path: <gcc-bugs-return-446664-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9761 invoked by alias); 18 Mar 2014 10:11:58 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9696 invoked by uid 55); 18 Mar 2014 10:11:51 -0000
From: "skrll at netbsd dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60039] sh3 optimisation bug with -O2
Date: Tue, 18 Mar 2014 10:11: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.8.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: skrll at netbsd dot org
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:
Message-ID: <bug-60039-4-KXVZXfYtN7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60039-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60039-4@http.gcc.gnu.org/bugzilla/>
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-03/txt/msg01533.txt.bz2
Content-length: 996
http://gcc.gnu.org/bugzilla/show_bug.cgi?id`039
--- Comment #8 from Nick Hudson <skrll at netbsd dot org> ---
On 03/18/14 02:34, kkojima at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id`039
>
> --- Comment #7 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
> Ugh, then this is an old problem and we've missed to give a correct
> clobber information to udivsi3_i1 insn for PIC. Does the patch
> below fix the issue?
>
> --- gcc/config/sh/sh.md.orig 2013-09-13 17:38:22.000000000 +0900
> +++ gcc/config/sh/sh.md 2014-03-18 11:08:19.868887133 +0900
> @@ -2152,6 +2152,7 @@
> (udiv:SI (reg:SI R4_REG) (reg:SI R5_REG)))
> (clobber (reg:SI T_REG))
> (clobber (reg:SI PR_REG))
> + (clobber (reg:SI R1_REG))
> (clobber (reg:SI R4_REG))
> (use (match_operand:SI 1 "arith_reg_operand" "r"))]
> "TARGET_SH1 && TARGET_DIVIDE_CALL_DIV1"
>
yes, this patch helps ld.elf_so.
I seem to have a different problem in libc now.
Thanks,
Nick
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-03-18 21:10 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-18 9:59 [Bug target/60562] New: ’4.9 Regression] FAIL: gcc.target/i386/excess-precision-3.c execution test on x86_64-apple-darwin13 dominiq at lps dot ens.fr
2014-03-18 11:48 ` [Bug target/60562] [4.9 " rguenth at gcc dot gnu.org
2014-03-18 13:14 ` [Bug target/60562] [4.9 Regression] FAIL: gcc.target/i386/excess-precision-3.c execution test after r208587 dominiq at lps dot ens.fr
2014-03-18 14:36 ` jakub at gcc dot gnu.org
2014-03-18 15:30 ` rth at gcc dot gnu.org
2014-03-18 20:25 ` rth at gcc dot gnu.org
2014-03-18 20:26 ` rth at gcc dot gnu.org
2014-03-18 21:10 ` dominiq at lps dot ens.fr
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).