* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
@ 2013-12-06 17:55 ` hjl.tools at gmail dot com
2013-12-06 21:52 ` hjl.tools at gmail dot com
` (19 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-06 17:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-12-06
CC| |rguenther at suse dot de
Target Milestone|--- |4.9.0
Ever confirmed|0 |1
--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
It is caused by r205730. When the x32 perlbmk binary is running.
it causes
*** Error in `../00000002/perlbmk_peak.lto': malloc(): memory corruption
(fast): 0x00fcd640 ***
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
2013-12-06 17:55 ` [Bug middle-end/59409] " hjl.tools at gmail dot com
@ 2013-12-06 21:52 ` hjl.tools at gmail dot com
2013-12-06 23:30 ` hjl.tools at gmail dot com
` (18 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-06 21:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
Revert
--
diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index f2fdc99..380fd22 100644
--- a/gcc/tree-vect-loop-manip.c
+++ b/gcc/tree-vect-loop-manip.c
@@ -1061,7 +1061,6 @@ slpeel_tree_peel_loop_to_edge (struct loop *loop,
gimple_stmt_iterator gsi;
edge exit_e = single_exit (loop);
source_location loop_loc;
- tree cost_pre_condition = NULL_TREE;
/* There are many aspects to how likely the first loop is going to be
executed.
Without histogram we can't really do good job. Simply set it to
2/3, so the first loop is not reordered to the end of function and
@@ -1263,21 +1262,17 @@ slpeel_tree_peel_loop_to_edge (struct loop *loop,
/* Epilogue peeling. */
if (!update_first_loop_count)
{
+ loop_vec_info loop_vinfo = loop_vec_info_for_loop (loop);
+ tree scalar_loop_iters = LOOP_VINFO_NITERSM1 (loop_vinfo);
+ unsigned limit = LOOP_VINFO_VECT_FACTOR (loop_vinfo) - 1;
+ if (LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo))
+ limit = limit + 1;
+ if (check_profitability
+ && th > limit)
+ limit = th;
pre_condition =
- fold_build2 (LE_EXPR, boolean_type_node, *first_niters,
- build_int_cst (TREE_TYPE (*first_niters), 0));
- if (check_profitability)
- {
- tree scalar_loop_iters
- = unshare_expr (LOOP_VINFO_NITERS_UNCHANGED
- (loop_vec_info_for_loop (loop)));
- cost_pre_condition =
- fold_build2 (LE_EXPR, boolean_type_node, scalar_loop_iters,
- build_int_cst (TREE_TYPE (scalar_loop_iters), th));
-
- pre_condition = fold_build2 (TRUTH_OR_EXPR, boolean_type_node,
- cost_pre_condition, pre_condition);
- }
+ fold_build2 (LT_EXPR, boolean_type_node, scalar_loop_iters,
+ build_int_cst (TREE_TYPE (scalar_loop_iters), limit));
if (cond_expr)
{
pre_condition =
--
fixes the regression. But pr59058.c fails.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
2013-12-06 17:55 ` [Bug middle-end/59409] " hjl.tools at gmail dot com
2013-12-06 21:52 ` hjl.tools at gmail dot com
@ 2013-12-06 23:30 ` hjl.tools at gmail dot com
2013-12-06 23:50 ` hjl.tools at gmail dot com
` (17 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-06 23:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
slpeel_tree_peel_loop_to_edge has comments:
The first guard is:
if (FIRST_NITERS == 0) then skip the first loop,
and go directly to the second loop.
This is removed by r205730.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (2 preceding siblings ...)
2013-12-06 23:30 ` hjl.tools at gmail dot com
@ 2013-12-06 23:50 ` hjl.tools at gmail dot com
2013-12-07 0:00 ` hjl.tools at gmail dot com
` (16 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-06 23:50 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
Should it consider both *first_niters and scalar_loop_iters?
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (3 preceding siblings ...)
2013-12-06 23:50 ` hjl.tools at gmail dot com
@ 2013-12-07 0:00 ` hjl.tools at gmail dot com
2013-12-07 4:14 ` hjl.tools at gmail dot com
` (15 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-07 0:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to H.J. Lu from comment #4)
> Should it consider both *first_niters and scalar_loop_iters?
Something like this
diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index 380fd22..3f85cc1 100644
--- a/gcc/tree-vect-loop-manip.c
+++ b/gcc/tree-vect-loop-manip.c
@@ -1265,6 +1265,7 @@ slpeel_tree_peel_loop_to_edge (struct loop *loop,
loop_vec_info loop_vinfo = loop_vec_info_for_loop (loop);
tree scalar_loop_iters = LOOP_VINFO_NITERSM1 (loop_vinfo);
unsigned limit = LOOP_VINFO_VECT_FACTOR (loop_vinfo) - 1;
+ tree cmp_condition;
if (LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo))
limit = limit + 1;
if (check_profitability
@@ -1273,6 +1274,17 @@ slpeel_tree_peel_loop_to_edge (struct loop *loop,
pre_condition =
fold_build2 (LT_EXPR, boolean_type_node, scalar_loop_iters,
build_int_cst (TREE_TYPE (scalar_loop_iters), limit));
+ cmp_condition =
+ fold_build2 (LT_EXPR, boolean_type_node, scalar_loop_iters,
+ *first_niters);
+ cmp_condition =
+ fold_build2 (TRUTH_AND_EXPR, boolean_type_node,
+ cmp_condition,
+ fold_build2 (LE_EXPR, boolean_type_node, *first_niters,
+ build_int_cst (TREE_TYPE (*first_niters), 0)));
+ pre_condition =
+ fold_build2 (TRUTH_OR_EXPR, boolean_type_node,
+ pre_condition, cmp_condition);
if (cond_expr)
{
pre_condition =
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (4 preceding siblings ...)
2013-12-07 0:00 ` hjl.tools at gmail dot com
@ 2013-12-07 4:14 ` hjl.tools at gmail dot com
2013-12-07 9:52 ` rguenther at suse dot de
` (14 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-07 4:14 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
Starting program:
/export/project/git/gcc-regression/spec/2000/spec/benchspec/CINT2000/253.perlbmk/run/00000002/../00000002/perlbmk_peak.lto
-I./lib diffmail.pl 2 550 15 24 23 100 > /dev/null
Program received signal SIGSEGV, Segmentation fault.
Perl_sv_setsv (dstr=<optimized out>, sstr=<optimized out>) at sv.c:1955
1955 stype = SvTYPE(sstr);
Missing separate debuginfos, use: debuginfo-install glibc-2.17-20.0.fc19.x32
(gdb) list
1950 if (sstr == dstr)
1951 return;
1952 SV_CHECK_THINKFIRST(dstr);
1953 if (!sstr)
1954 sstr = &PL_sv_undef;
1955 stype = SvTYPE(sstr);
1956 dtype = SvTYPE(dstr);
1957
1958 if (dtype == SVt_PVGV && (SvFLAGS(dstr) & SVf_FAKE)) {
1959 sv_unglob(dstr); /* so fake GLOB won't perpetuate */
(gdb) bt
#0 Perl_sv_setsv (dstr=<optimized out>, sstr=<optimized out>) at sv.c:1955
#1 0x00494269 in Perl_sv_mortalcopy (oldstr=<optimized out>) at sv.c:3658
#2 0x004409ad in Perl_pp_aassign () at pp_hot.c:599
#3 0x004e6ac6 in Perl_runops_standard () at run.c:30
#4 0x004339fc in perl_run (sv_interp=<optimized out>) at perl.c:1100
#5 0x0040348b in main (argc=9, argv=<optimized out>, env=<optimized out>)
at unix_perlmain.c:51
(gdb)
Dump of assembler code for function Perl_sv_setsv:
0x00490260 <+0>: push %r15
0x00490262 <+2>: push %r14
0x00490264 <+4>: push %r13
0x00490266 <+6>: push %r12
0x00490268 <+8>: push %rbp
0x00490269 <+9>: push %rbx
0x0049026a <+10>: mov %rdi,%rbx
0x0049026d <+13>: sub $0x18,%esp
0x00490270 <+16>: cmp %edi,%esi
0x00490272 <+18>: je 0x490428 <Perl_sv_setsv+456>
0x00490278 <+24>: mov 0x8(%edi),%eax
0x0049027c <+28>: test $0x880000,%eax
0x00490281 <+33>: jne 0x490440 <Perl_sv_setsv+480>
0x00490287 <+39>: test %rsi,%rsi
0x0049028a <+42>: mov $0x7105b4,%ebp
0x0049028f <+47>: movzbl %al,%r13d
0x00490293 <+51>: cmovne %rsi,%rbp
0x00490297 <+55>: cmp $0xd,%r13d
=> 0x0049029b <+59>: movzbl 0x8(%ebp),%r15d
0x004902a1 <+65>: je 0x4904c0 <Perl_sv_setsv+608>
0x004902a7 <+71>: mov %eax,%edi
(gdb) p/x $rsi
$15 = 0x622e656c
(gdb) p/x $rbp
$16 = 0x622e656c
(gdb) p *(SV *)0x622e656c
Cannot access memory at address 0x622e656c
(gdb)
sstr isn't NULL, but points to the wrong address. The loop is
if (PL_op->op_private & OPpASSIGN_COMMON) {
for (relem = firstrelem; relem <= lastrelem; relem++) {
/*SUPPRESS 560*/
if (sv = *relem) {
TAINT_NOT; /* Each item is independent */
*relem = sv_mortalcopy(sv);
}
}
}
Wrong value of sv is passed to sv_mortalcopy. The bad loop is
44085c: 0f 84 56 02 00 00 je 440ab8 <Perl_pp_aassign+0x2c8>
440862: 67 44 8b 74 24 48 mov 0x48(%esp),%r14d
440868: 44 39 f3 cmp %r14d,%ebx
44086b: 0f 82 47 02 00 00 jb 440ab8 <Perl_pp_aassign+0x2c8>
440871: 41 89 ff mov %edi,%r15d
440874: 67 41 8b 06 mov (%r14d),%eax
440878: 45 29 f7 sub %r14d,%r15d
44087b: 41 c1 ef 02 shr $0x2,%r15d
44087f: 41 83 e7 07 and $0x7,%r15d
440883: 85 c0 test %eax,%eax
440885: 0f 84 69 14 00 00 je 441cf4 <Perl_pp_aassign+0x1504>
44088b: 89 c7 mov %eax,%edi
44088d: c6 05 79 fd 2c 00 00 movb $0x0,0x2cfd79(%rip) #
71060d <PL_tainted>
440894: e8 87 39 05 00 callq 494220 <Perl_sv_mortalcopy>
440899: 67 8b 54 24 48 mov 0x48(%esp),%edx
44089e: 67 89 02 mov %eax,(%edx)
4408a1: 89 d6 mov %edx,%esi
4408a3: 8d 5e 04 lea 0x4(%rsi),%ebx
4408a6: 67 39 5c 24 10 cmp %ebx,0x10(%esp)
4408ab: 0f 82 07 02 00 00 jb 440ab8 <Perl_pp_aassign+0x2c8>
4408b1: 45 85 ff test %r15d,%r15d
4408b4: 0f 84 04 01 00 00 je 4409be <Perl_pp_aassign+0x1ce>
4408ba: 41 83 ff 01 cmp $0x1,%r15d
4408be: 0f 84 d1 00 00 00 je 440995 <Perl_pp_aassign+0x1a5>
4408c4: 41 83 ff 02 cmp $0x2,%r15d
4408c8: 0f 84 a9 00 00 00 je 440977 <Perl_pp_aassign+0x187>
4408ce: 41 83 ff 03 cmp $0x3,%r15d
4408d2: 0f 84 81 00 00 00 je 440959 <Perl_pp_aassign+0x169>
4408d8: 41 83 ff 04 cmp $0x4,%r15d
4408dc: 74 5d je 44093b <Perl_pp_aassign+0x14b>
4408de: 41 83 ff 05 cmp $0x5,%r15d
4408e2: 74 3c je 440920 <Perl_pp_aassign+0x130>
4408e4: 41 83 ff 06 cmp $0x6,%r15d
4408e8: 74 1b je 440905 <Perl_pp_aassign+0x115>
4408ea: 67 8b 0b mov (%ebx),%ecx
4408ed: 85 c9 test %ecx,%ecx
4408ef: 74 11 je 440902 <Perl_pp_aassign+0x112>
4408f1: 89 cf mov %ecx,%edi
4408f3: c6 05 13 fd 2c 00 00 movb $0x0,0x2cfd13(%rip) #
71060d <PL_tainted>
4408fa: e8 21 39 05 00 callq 494220 <Perl_sv_mortalcopy>
4408ff: 67 89 03 mov %eax,(%ebx)
440902: 83 c3 04 add $0x4,%ebx
440905: 67 8b 3b mov (%ebx),%edi
440908: 85 ff test %edi,%edi
44090a: 74 11 je 44091d <Perl_pp_aassign+0x12d>
44090c: 89 ff mov %edi,%edi
44090e: c6 05 f8 fc 2c 00 00 movb $0x0,0x2cfcf8(%rip) #
71060d <PL_tainted>
440915: e8 06 39 05 00 callq 494220 <Perl_sv_mortalcopy>
44091a: 67 89 03 mov %eax,(%ebx)
44091d: 83 c3 04 add $0x4,%ebx
440920: 67 8b 2b mov (%ebx),%ebp
440923: 85 ed test %ebp,%ebp
440925: 74 11 je 440938 <Perl_pp_aassign+0x148>
440925: 74 11 je 440938 <Perl_pp_aassign+0x148>
440927: 89 ef mov %ebp,%edi
440929: c6 05 dd fc 2c 00 00 movb $0x0,0x2cfcdd(%rip) #
71060d <PL_tainted>
440930: e8 eb 38 05 00 callq 494220 <Perl_sv_mortalcopy>
440935: 67 89 03 mov %eax,(%ebx)
440938: 83 c3 04 add $0x4,%ebx
44093b: 67 44 8b 03 mov (%ebx),%r8d
44093f: 45 85 c0 test %r8d,%r8d
440942: 74 12 je 440956 <Perl_pp_aassign+0x166>
440944: 44 89 c7 mov %r8d,%edi
440947: c6 05 bf fc 2c 00 00 movb $0x0,0x2cfcbf(%rip) #
71060d <PL_tainted>
44094e: e8 cd 38 05 00 callq 494220 <Perl_sv_mortalcopy>
440953: 67 89 03 mov %eax,(%ebx)
440956: 83 c3 04 add $0x4,%ebx
440959: 67 44 8b 0b mov (%ebx),%r9d
44095d: 45 85 c9 test %r9d,%r9d
440960: 74 12 je 440974 <Perl_pp_aassign+0x184>
440962: 44 89 cf mov %r9d,%edi
440965: c6 05 a1 fc 2c 00 00 movb $0x0,0x2cfca1(%rip) #
71060d <PL_tainted>
44096c: e8 af 38 05 00 callq 494220 <Perl_sv_mortalcopy>
440971: 67 89 03 mov %eax,(%ebx)
440974: 83 c3 04 add $0x4,%ebx
440977: 67 44 8b 13 mov (%ebx),%r10d
44097b: 45 85 d2 test %r10d,%r10d
44097e: 74 12 je 440992 <Perl_pp_aassign+0x1a2>
440980: 44 89 d7 mov %r10d,%edi
440983: c6 05 83 fc 2c 00 00 movb $0x0,0x2cfc83(%rip) #
71060d <PL_tainted>
44098a: e8 91 38 05 00 callq 494220 <Perl_sv_mortalcopy>
44098f: 67 89 03 mov %eax,(%ebx)
440992: 83 c3 04 add $0x4,%ebx
440995: 67 44 8b 1b mov (%ebx),%r11d
440999: 45 85 db test %r11d,%r11d
44099c: 74 12 je 4409b0 <Perl_pp_aassign+0x1c0>
44099e: 44 89 df mov %r11d,%edi
4409a1: c6 05 65 fc 2c 00 00 movb $0x0,0x2cfc65(%rip) #
71060d <PL_tainted>
4409a8: e8 73 38 05 00 callq 494220 <Perl_sv_mortalcopy>
4409ad: 67 89 03 mov %eax,(%ebx)
4409b0: 83 c3 04 add $0x4,%ebx
4409b3: 67 39 5c 24 10 cmp %ebx,0x10(%esp)
4409b8: 0f 82 fa 00 00 00 jb 440ab8 <Perl_pp_aassign+0x2c8>
4409be: 67 44 8b 23 mov (%ebx),%r12d
4409c2: 45 85 e4 test %r12d,%r12d
4409c5: 74 12 je 4409d9 <Perl_pp_aassign+0x1e9>
4409c7: 44 89 e7 mov %r12d,%edi
4409ca: c6 05 3c fc 2c 00 00 movb $0x0,0x2cfc3c(%rip) #
71060d <PL_tainted>
4409d1: e8 4a 38 05 00 callq 494220 <Perl_sv_mortalcopy>
4409d6: 67 89 03 mov %eax,(%ebx)
4409d9: 67 44 8b 73 04 mov 0x4(%ebx),%r14d
4409de: 44 8d 6b 04 lea 0x4(%rbx),%r13d
4409e2: 45 85 f6 test %r14d,%r14d
4409e5: 74 13 je 4409fa <Perl_pp_aassign+0x20a>
4409e7: 44 89 f7 mov %r14d,%edi
4409ea: c6 05 1c fc 2c 00 00 movb $0x0,0x2cfc1c(%rip) #
71060d <PL_tainted>
4409f1: e8 2a 38 05 00 callq 494220 <Perl_sv_mortalcopy>
4409f6: 67 89 43 04 mov %eax,0x4(%ebx)
4409fa: 67 41 8b 5d 04 mov 0x4(%r13d),%ebx
4409ff: 85 db test %ebx,%ebx
440a01: 74 13 je 440a16 <Perl_pp_aassign+0x226>
440a03: 89 df mov %ebx,%edi
440a05: c6 05 01 fc 2c 00 00 movb $0x0,0x2cfc01(%rip) #
71060d <PL_tainted>
440a0c: e8 0f 38 05 00 callq 494220 <Perl_sv_mortalcopy>
440a11: 67 41 89 45 04 mov %eax,0x4(%r13d)
440a16: 67 45 8b 7d 08 mov 0x8(%r13d),%r15d
440a1b: 45 85 ff test %r15d,%r15d
440a1e: 74 14 je 440a34 <Perl_pp_aassign+0x244>
440a20: 44 89 ff mov %r15d,%edi
440a23: c6 05 e3 fb 2c 00 00 movb $0x0,0x2cfbe3(%rip) #
71060d <PL_tainted>
440a2a: e8 f1 37 05 00 callq 494220 <Perl_sv_mortalcopy>
440a2f: 67 41 89 45 08 mov %eax,0x8(%r13d)
440a34: 67 41 8b 45 0c mov 0xc(%r13d),%eax
440a39: 85 c0 test %eax,%eax
440a3b: 74 13 je 440a50 <Perl_pp_aassign+0x260>
440a3d: 89 c7 mov %eax,%edi
440a3f: c6 05 c7 fb 2c 00 00 movb $0x0,0x2cfbc7(%rip) #
71060d <PL_tainted>
440a46: e8 d5 37 05 00 callq 494220 <Perl_sv_mortalcopy>
440a4b: 67 41 89 45 0c mov %eax,0xc(%r13d)
440a50: 67 41 8b 55 10 mov 0x10(%r13d),%edx
440a55: 85 d2 test %edx,%edx
440a57: 74 13 je 440a6c <Perl_pp_aassign+0x27c>
440a59: 89 d7 mov %edx,%edi
440a5b: c6 05 ab fb 2c 00 00 movb $0x0,0x2cfbab(%rip) #
71060d <PL_tainted>
440a62: e8 b9 37 05 00 callq 494220 <Perl_sv_mortalcopy>
440a67: 67 41 89 45 10 mov %eax,0x10(%r13d)
440a6c: 67 41 8b 75 14 mov 0x14(%r13d),%esi
440a71: 85 f6 test %esi,%esi
440a73: 74 13 je 440a88 <Perl_pp_aassign+0x298>
440a75: 89 f7 mov %esi,%edi
440a77: c6 05 8f fb 2c 00 00 movb $0x0,0x2cfb8f(%rip) #
71060d <PL_tainted>
440a7e: e8 9d 37 05 00 callq 494220 <Perl_sv_mortalcopy>
440a83: 67 41 89 45 14 mov %eax,0x14(%r13d)
440a88: 67 41 8b 4d 18 mov 0x18(%r13d),%ecx
440a8d: 85 c9 test %ecx,%ecx
440a8f: 74 13 je 440aa4 <Perl_pp_aassign+0x2b4>
440a91: 89 cf mov %ecx,%edi
440a93: c6 05 73 fb 2c 00 00 movb $0x0,0x2cfb73(%rip) #
71060d <PL_tainted>
440a9a: e8 81 37 05 00 callq 494220 <Perl_sv_mortalcopy>
440a9f: 67 41 89 45 18 mov %eax,0x18(%r13d)
440aa4: 41 8d 5d 1c lea 0x1c(%r13),%ebx
440aa8: 67 39 5c 24 10 cmp %ebx,0x10(%esp)
440aad: 0f 83 0b ff ff ff jae 4409be <Perl_pp_aassign+0x1ce>
440ab3: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
440ab8: 67 8b 7c 24 4c mov 0x4c(%esp),%edi
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (5 preceding siblings ...)
2013-12-07 4:14 ` hjl.tools at gmail dot com
@ 2013-12-07 9:52 ` rguenther at suse dot de
2013-12-07 11:22 ` hjl.tools at gmail dot com
` (13 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenther at suse dot de @ 2013-12-07 9:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
"hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org> wrote:
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
>
>--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
>slpeel_tree_peel_loop_to_edge has comments:
>
> The first guard is:
> if (FIRST_NITERS == 0) then skip the first loop,
> and go directly to the second loop.
>
>This is removed by r205730.
It's implemented in terms of scalar loop iterations (latch execution count).
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (6 preceding siblings ...)
2013-12-07 9:52 ` rguenther at suse dot de
@ 2013-12-07 11:22 ` hjl.tools at gmail dot com
2013-12-07 15:54 ` rguenther at suse dot de
` (12 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-07 11:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to rguenther@suse.de from comment #7)
> "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org> wrote:
> >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
> >
> >--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
> >slpeel_tree_peel_loop_to_edge has comments:
> >
> > The first guard is:
> > if (FIRST_NITERS == 0) then skip the first loop,
> > and go directly to the second loop.
> >
> >This is removed by r205730.
>
> It's implemented in terms of scalar loop iterations (latch execution count).
Is that ever possible to have latch execution count < 0
and FIRST_NITERS == 0? It happens in x32 253.perlbmk.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (7 preceding siblings ...)
2013-12-07 11:22 ` hjl.tools at gmail dot com
@ 2013-12-07 15:54 ` rguenther at suse dot de
2013-12-07 15:57 ` hjl.tools at gmail dot com
` (11 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenther at suse dot de @ 2013-12-07 15:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
"hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org> wrote:
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
>
>--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> ---
>(In reply to rguenther@suse.de from comment #7)
>> "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org> wrote:
>> >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
>> >
>> >--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
>> >slpeel_tree_peel_loop_to_edge has comments:
>> >
>> > The first guard is:
>> > if (FIRST_NITERS == 0) then skip the first loop,
>> > and go directly to the second loop.
>> >
>> >This is removed by r205730.
>>
>> It's implemented in terms of scalar loop iterations (latch execution
>count).
>
>Is that ever possible to have latch execution count < 0
>and FIRST_NITERS == 0? It happens in x32 253.perlbmk.
That should be impossible.
Richard.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (8 preceding siblings ...)
2013-12-07 15:54 ` rguenther at suse dot de
@ 2013-12-07 15:57 ` hjl.tools at gmail dot com
2013-12-07 16:05 ` hjl.tools at gmail dot com
` (10 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-07 15:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to rguenther@suse.de from comment #9)
> >
> >Is that ever possible to have latch execution count < 0
> >and FIRST_NITERS == 0? It happens in x32 253.perlbmk.
>
> That should be impossible.
>
That is what I thought too. But this patch
diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index 380fd22..68c24a0 100644
--- a/gcc/tree-vect-loop-manip.c
+++ b/gcc/tree-vect-loop-manip.c
@@ -1273,6 +1273,17 @@ slpeel_tree_peel_loop_to_edge (struct loop *loop,
pre_condition =
fold_build2 (LT_EXPR, boolean_type_node, scalar_loop_iters,
build_int_cst (TREE_TYPE (scalar_loop_iters), limit));
+ tree first_condition =
+ fold_build2 (LE_EXPR, boolean_type_node, *first_niters,
+ build_int_cst (TREE_TYPE (*first_niters), 0));
+ first_condition =
+ fold_build2 (TRUTH_AND_EXPR, boolean_type_node,
+ first_condition,
+ fold_build2 (LT_EXPR, boolean_type_node, scalar_loop_iters,
+ *first_niters));
+ pre_condition =
+ fold_build2 (TRUTH_OR_EXPR, boolean_type_node,
+ pre_condition, first_condition);
if (cond_expr)
{
pre_condition =
fixes the problem. But I can't explain why/how it can make
a difference at all.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (9 preceding siblings ...)
2013-12-07 15:57 ` hjl.tools at gmail dot com
@ 2013-12-07 16:05 ` hjl.tools at gmail dot com
2013-12-07 16:20 ` hjl.tools at gmail dot com
` (9 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-07 16:05 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #11 from H.J. Lu <hjl.tools at gmail dot com> ---
latch execution count can be an expression like "if (b)" in
gcc.dg/torture/pr59058.c. Will such an expression be possible
negative at run-time?
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (10 preceding siblings ...)
2013-12-07 16:05 ` hjl.tools at gmail dot com
@ 2013-12-07 16:20 ` hjl.tools at gmail dot com
2013-12-07 17:42 ` hjl.tools at gmail dot com
` (8 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-07 16:20 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #12 from H.J. Lu <hjl.tools at gmail dot com> ---
This function:
SV *
sv_mortalcopy(SV *oldstr)
{
dTHR;
register SV *sv;
new_SV(sv);
SvANY(sv) = 0;
SvREFCNT(sv) = 1;
SvFLAGS(sv) = 0;
sv_setsv(sv,oldstr);
if (++PL_tmps_ix >= PL_tmps_max)
sv_mortalgrow();
PL_tmps_stack[PL_tmps_ix] = sv;
SvTEMP_on(sv);
return sv;
}
is compiled into
00494220 <Perl_sv_mortalcopy>:
494220: 41 54 push %r12
494222: 55 push %rbp
494223: 48 89 fe mov %rdi,%rsi
494226: 53 push %rbx
494227: 83 ec 10 sub $0x10,%esp
49422a: 8b 1d c0 c3 27 00 mov 0x27c3c0(%rip),%ebx #
7105f0 <PL_sv_root>
494230: 85 db test %ebx,%ebx
494232: 0f 84 e0 00 00 00 je 494318 <Perl_sv_mortalcopy+0xf8>
494238: 67 8b 03 mov (%ebx),%eax
49423b: 83 05 aa c3 27 00 01 addl $0x1,0x27c3aa(%rip) #
7105ec <PL_sv_count>
494242: 89 05 a8 c3 27 00 mov %eax,0x27c3a8(%rip) #
7105f0 <PL_sv_root>
494248: 89 dd mov %ebx,%ebp
49424a: 67 c7 03 00 00 00 00 movl $0x0,(%ebx)
494251: 67 c7 43 04 01 00 00 00 movl $0x1,0x4(%ebx)
494259: 48 89 ef mov %rbp,%rdi
49425c: 67 c7 43 08 00 00 00 00 movl $0x0,0x8(%ebx)
494264: e8 f7 bf ff ff callq 490260 <Perl_sv_setsv>
494269: 8b 15 41 b5 27 00 mov 0x27b541(%rip),%edx #
70f7b0 <PL_tmps_ix>
49426f: 8b 3d 03 bd 27 00 mov 0x27bd03(%rip),%edi #
70ff78 <PL_tmps_max>
494275: 44 8b 15 3c c0 27 00 mov 0x27c03c(%rip),%r10d #
7102b8 <PL_tmps_stack>
49427c: 44 8d 4a 01 lea 0x1(%rdx),%r9d
494280: 41 39 f9 cmp %edi,%r9d
494283: 44 89 0d 26 b5 27 00 mov %r9d,0x27b526(%rip) #
70f7b0 <PL_tmps_ix>
49428a: 7d 1c jge 4942a8 <Perl_sv_mortalcopy+0x88>
49428c: 67 43 89 1c 8a mov %ebx,(%r10d,%r9d,4)
494291: 67 81 4b 08 00 08 00 00 orl $0x800,0x8(%ebx)
494299: 83 c4 10 add $0x10,%esp
49429c: 48 89 e8 mov %rbp,%rax
49429f: 5b pop %rbx
4942a0: 5d pop %rbp
4942a1: 41 5c pop %r12
4942a3: c3 retq
4942a4: 0f 1f 40 00 nopl 0x0(%rax)
4942a8: be 00 02 00 00 mov $0x200,%esi
4942ad: 81 ff 00 02 00 00 cmp $0x200,%edi
4942b3: 41 b8 80 00 00 00 mov $0x80,%r8d
4942b9: 89 f1 mov %esi,%ecx
4942bb: 41 0f 4c c8 cmovl %r8d,%ecx
4942bf: 8d 34 0f lea (%rdi,%rcx,1),%esi
4942c2: 8b 3d f0 bf 27 00 mov 0x27bff0(%rip),%edi #
7102b8 <PL_tmps_stack>
4942c8: 89 35 aa bc 27 00 mov %esi,0x27bcaa(%rip) #
70ff78 <PL_tmps_max>
4942ce: c1 e6 02 shl $0x2,%esi
4942d1: 85 f6 test %esi,%esi
4942d3: 74 2b je 494300 <Perl_sv_mortalcopy+0xe0>
4942d5: 85 ff test %edi,%edi
4942d7: 74 6f je 494348 <Perl_sv_mortalcopy+0x128>
4942d9: e8 52 d6 f6 ff callq 401930 <realloc@plt>
4942de: 85 c0 test %eax,%eax
4942e0: 74 4e je 494330 <Perl_sv_mortalcopy+0x110>
4942e2: 44 8b 0d c7 b4 27 00 mov 0x27b4c7(%rip),%r9d #
70f7b0 <PL_tmps_ix>
4942e9: 41 89 c4 mov %eax,%r12d
4942ec: 44 89 25 c5 bf 27 00 mov %r12d,0x27bfc5(%rip) #
7102b8 <PL_tmps_stack>
4942f3: 45 89 e2 mov %r12d,%r10d
4942f6: eb 94 jmp 49428c <Perl_sv_mortalcopy+0x6c>
4942f8: 0f 1f 84 00 00 00 00 00 nopl 0x0(%rax,%rax,1)
494300: 45 31 e4 xor %r12d,%r12d
494303: 85 ff test %edi,%edi
494305: 74 e5 je 4942ec <Perl_sv_mortalcopy+0xcc>
494307: e8 b4 d1 f6 ff callq 4014c0 <free@plt>
49430c: 44 8b 0d 9d b4 27 00 mov 0x27b49d(%rip),%r9d #
70f7b0 <PL_tmps_ix>
494313: eb d7 jmp 4942ec <Perl_sv_mortalcopy+0xcc>
494315: 0f 1f 00 nopl (%rax)
494318: 67 48 89 7c 24 08 mov %rdi,0x8(%esp)
49431e: e8 2d de fe ff callq 482150 <more_sv.lto_priv.92>
494323: 67 48 8b 74 24 08 mov 0x8(%esp),%rsi
494329: 89 c3 mov %eax,%ebx
49432b: e9 18 ff ff ff jmpq 494248 <Perl_sv_mortalcopy+0x28>
494330: 80 3d cd c2 27 00 00 cmpb $0x0,0x27c2cd(%rip) #
710604 <PL_nomemok>
494337: 74 27 je 494360 <Perl_sv_mortalcopy+0x140>
494339: 44 8b 0d 70 b4 27 00 mov 0x27b470(%rip),%r9d #
70f7b0 <PL_tmps_ix>
494340: 45 31 e4 xor %r12d,%r12d
494343: eb a7 jmp 4942ec <Perl_sv_mortalcopy+0xcc>
494345: 0f 1f 00 nopl (%rax)
494348: 89 f7 mov %esi,%edi
49434a: e8 11 9d 01 00 callq 4ae060 <Perl_safemalloc>
49434f: 44 8b 0d 5a b4 27 00 mov 0x27b45a(%rip),%r9d #
70f7b0 <PL_tmps_ix>
494356: 41 89 c4 mov %eax,%r12d
494359: eb 91 jmp 4942ec <Perl_sv_mortalcopy+0xcc>
49435b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
494360: 8b 0d fe b8 27 00 mov 0x27b8fe(%rip),%ecx #
70fc64 <stderr@@GLIBC_2.16>
494366: ba 0f 00 00 00 mov $0xf,%edx
49436b: be 01 00 00 00 mov $0x1,%esi
494370: bf f0 fe 4f 00 mov $0x4ffef0,%edi
494375: e8 d6 d1 f6 ff callq 401550 <fwrite@plt>
49437a: e8 c1 08 04 00 callq 4d4c40 <Perl_my_exit.constprop.28>
49437f: eb b8 jmp 494339 <Perl_sv_mortalcopy+0x119>
494381: 66 2e 0f 1f 84 00 00 00 00 00 nopw %cs:0x0(%rax,%rax,1)
49438b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
This may be miscompiled.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (11 preceding siblings ...)
2013-12-07 16:20 ` hjl.tools at gmail dot com
@ 2013-12-07 17:42 ` hjl.tools at gmail dot com
2013-12-07 17:56 ` hjl.tools at gmail dot com
` (7 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-07 17:42 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> ---
loop in Perl_pp_aassign is miscompiled:
44098a: e8 91 38 05 00 callq 494220 <Perl_sv_mortalcopy>
44098f: 67 89 03 mov %eax,(%ebx)
440992: 83 c3 04 add $0x4,%ebx
440995: 67 44 8b 1b mov (%ebx),%r11d
440999: 45 85 db test %r11d,%r11d
44099c: 74 12 je 4409b0 <Perl_pp_aassign+0x1c0>
44099e: 44 89 df mov %r11d,%edi
$r11d has invalid memory address.
4409a1: c6 05 65 fc 2c 00 00 movb $0x0,0x2cfc65(%rip) #
71060d <PL_tainted>
4409a8: e8 73 38 05 00 callq 494220 <Perl_sv_mortalcopy>
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (12 preceding siblings ...)
2013-12-07 17:42 ` hjl.tools at gmail dot com
@ 2013-12-07 17:56 ` hjl.tools at gmail dot com
2013-12-08 21:37 ` hjl.tools at gmail dot com
` (6 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-07 17:56 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #14 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to H.J. Lu from comment #13)
> loop in Perl_pp_aassign is miscompiled:
>
> 44098a: e8 91 38 05 00 callq 494220 <Perl_sv_mortalcopy>
> 44098f: 67 89 03 mov %eax,(%ebx)
> 440992: 83 c3 04 add $0x4,%ebx
> 440995: 67 44 8b 1b mov (%ebx),%r11d
> 440999: 45 85 db test %r11d,%r11d
> 44099c: 74 12 je 4409b0 <Perl_pp_aassign+0x1c0>
> 44099e: 44 89 df mov %r11d,%edi
>
> $r11d has invalid memory address.
>
> 4409a1: c6 05 65 fc 2c 00 00 movb $0x0,0x2cfc65(%rip) #
> 71060d <PL_tainted>
> 4409a8: e8 73 38 05 00 callq 494220 <Perl_sv_mortalcopy>
Loop is
for (relem = firstrelem; relem <= p; relem++) {
/*SUPPRESS 560*/
if (sv = *relem) {
TAINT_NOT; /* Each item is independent */
*relem = sv_mortalcopy(sv);
}
It was unrolled into
sv = *relem
TAINT_NOT
eax = Perl_sv_mortalcopy (sv)
*relem = eax
eax += 4;
sv = *(SV **) eax
TAINT_NOT
eax = Perl_sv_mortalcopy (sv)
I don't see how "eax += 4" can be correct. Return from
Perl_sv_mortalcopy is unrelated to relem.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (13 preceding siblings ...)
2013-12-07 17:56 ` hjl.tools at gmail dot com
@ 2013-12-08 21:37 ` hjl.tools at gmail dot com
2013-12-08 21:50 ` hjl.tools at gmail dot com
` (5 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-08 21:37 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #15 from H.J. Lu <hjl.tools at gmail dot com> ---
This
char *
my_bcopy(register char *from,register char *to,register I32 len)
{
char *retval = to;
if (from - to >= 0) {
while (len--)
*to++ = *from++;
}
else {
to += len;
from += len;
while (len--)
*(--to) = *(--from);
}
return retval;
}
may be miscompiled.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (14 preceding siblings ...)
2013-12-08 21:37 ` hjl.tools at gmail dot com
@ 2013-12-08 21:50 ` hjl.tools at gmail dot com
2013-12-08 22:36 ` hjl.tools at gmail dot com
` (4 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-08 21:50 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #16 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to H.J. Lu from comment #15)
> This
>
> char *
> my_bcopy(register char *from,register char *to,register I32 len)
> {
> char *retval = to;
>
> if (from - to >= 0) {
> while (len--)
> *to++ = *from++;
> }
> else {
> to += len;
> from += len;
> while (len--)
> *(--to) = *(--from);
> }
> return retval;
> }
>
> may be miscompiled.
With LTO, it is inlined. We got len == -1:
(gdb) bt
#0 Perl_my_bcopy (len=-1, to=0xf7fd803c "\260Vx", from=<optimized out>) at
util.c:1559
#1 Perl_pp_rv2av () at pp_hot.c:474
#2 0x004e6ac6 in Perl_runops_standard () at run.c:30
#3 0x004339fc in perl_run (sv_interp=<optimized out>) at perl.c:1100
#4 0x0040348b in main (argc=9, argv=<optimized out>, env=<optimized out>)
at unix_perlmain.c:51
(gdb)
Should len == -1 here?
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (15 preceding siblings ...)
2013-12-08 21:50 ` hjl.tools at gmail dot com
@ 2013-12-08 22:36 ` hjl.tools at gmail dot com
2013-12-09 1:32 ` hjl.tools at gmail dot com
` (3 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-08 22:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #17 from H.J. Lu <hjl.tools at gmail dot com> ---
Perl_my_bcopy (len=31, to=0xf7fd801d "\021q", from=0x8023f0 "\264\005q")
is miscompiled when inlined:
Old value = 19935280
New value = 808464432
Perl_my_bcopy (len=-1, to=0xf7fd803c "\260Vx", from=<optimized out>) at
util.c:1559
1559 while (len--)
The last write is to 4-bytes at 0xf7fd803b:
442dd7: 83 fe 0b cmp $0xb,%esi
442dda: 67 44 88 42 0b mov %r8b,0xb(%edx)
442ddf: 74 27 je 442e08 <Perl_pp_rv2av+0x898>
(gdb) p/x $edx
$300 = 0xf7fd8030
(gdb) p/x $edx + 0xb
$301 = 0xf7fd803b
(gdb)
But the last byte should be written at 0xf7fd801d + 30 == 0xf7fd803b.
There are 3 byte overflow for write. I will see if I can write a
testcase.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (16 preceding siblings ...)
2013-12-08 22:36 ` hjl.tools at gmail dot com
@ 2013-12-09 1:32 ` hjl.tools at gmail dot com
2013-12-09 9:19 ` rguenther at suse dot de
` (2 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-09 1:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #18 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to H.J. Lu from comment #17)
> Perl_my_bcopy (len=31, to=0xf7fd801d "\021q", from=0x8023f0 "\264\005q")
> is miscompiled when inlined:
>
> Old value = 19935280
> New value = 808464432
> Perl_my_bcopy (len=-1, to=0xf7fd803c "\260Vx", from=<optimized out>) at
> util.c:1559
> 1559 while (len--)
>
> The last write is to 4-bytes at 0xf7fd803b:
>
> 442dd7: 83 fe 0b cmp $0xb,%esi
> 442dda: 67 44 88 42 0b mov %r8b,0xb(%edx)
It is OK since it is a byte store.
> 442ddf: 74 27 je 442e08 <Perl_pp_rv2av+0x898>
>
> (gdb) p/x $edx
> $300 = 0xf7fd8030
> (gdb) p/x $edx + 0xb
> $301 = 0xf7fd803b
> (gdb)
>
> But the last byte should be written at 0xf7fd801d + 30 == 0xf7fd803b.
> There are 3 byte overflow for write. I will see if I can write a
> testcase.
>From gcc-bugs-return-437014-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 09 04:14:06 2013
Return-Path: <gcc-bugs-return-437014-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25100 invoked by alias); 9 Dec 2013 04:14:05 -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 24966 invoked by uid 48); 9 Dec 2013 04:13:59 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
Date: Mon, 09 Dec 2013 04:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: RESOLVED
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: bug_status resolution
Message-ID: <bug-59409-4-eNRTREYItI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59409-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59409-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: 2013-12/txt/msg00669.txt.bz2
Content-length: 456
http://gcc.gnu.org/bugzilla/show_bug.cgi?idY409
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #19 from H.J. Lu <hjl.tools at gmail dot com> ---
Adding -fno-strict-aliasing fixed the problem.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (17 preceding siblings ...)
2013-12-09 1:32 ` hjl.tools at gmail dot com
@ 2013-12-09 9:19 ` rguenther at suse dot de
2013-12-09 12:40 ` hjl.tools at gmail dot com
2013-12-09 12:55 ` hjl.tools at gmail dot com
20 siblings, 0 replies; 22+ messages in thread
From: rguenther at suse dot de @ 2013-12-09 9:19 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 9 Dec 2013, hjl.tools at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
>
> H.J. Lu <hjl.tools at gmail dot com> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Status|NEW |RESOLVED
> Resolution|--- |INVALID
>
> --- Comment #19 from H.J. Lu <hjl.tools at gmail dot com> ---
> Adding -fno-strict-aliasing fixed the problem.
If using Perl_my_bcopy is the problem then maybe defining
HAS_SAFE_BCOPY will fix it?
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (18 preceding siblings ...)
2013-12-09 9:19 ` rguenther at suse dot de
@ 2013-12-09 12:40 ` hjl.tools at gmail dot com
2013-12-09 12:55 ` hjl.tools at gmail dot com
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-09 12:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #21 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to rguenther@suse.de from comment #20)
> > --- Comment #19 from H.J. Lu <hjl.tools at gmail dot com> ---
> > Adding -fno-strict-aliasing fixed the problem.
>
> If using Perl_my_bcopy is the problem then maybe defining
I can give it a try.
> HAS_SAFE_BCOPY will fix it?
It may be related to PR 33383.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/59409] [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled
2013-12-06 14:41 [Bug middle-end/59409] New: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is miscompiled hjl.tools at gmail dot com
` (19 preceding siblings ...)
2013-12-09 12:40 ` hjl.tools at gmail dot com
@ 2013-12-09 12:55 ` hjl.tools at gmail dot com
20 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-09 12:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #22 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to H.J. Lu from comment #21)
>
> > HAS_SAFE_BCOPY will fix it?
>
No, it doesn't work.
^ permalink raw reply [flat|nested] 22+ messages in thread